Central limit order book automatic triangulation system

ABSTRACT

The disclosed embodiments relate to systems and methods for triangulation of options and futures. An exchange receives a volatility quoted order. The system attempts to match the order within a volatility order book. If there is a match, the system attempts to mitigate the risk of the order by implying an order into the futures market. If there is not a match, the system implies an order into a premium quoted option order book. The exchange automatically maintains the order based on changes in the underlying futures market and a stored quoting model.

RELATED APPLICATIONS

This application claims priority to and the benefit as a continuationunder 37 C.F.R. 1.53(b) of U.S. patent application Ser. No. 17/672,185,filed Feb. 15, 2022, now U.S. Pat. No. ______, which claims priority toand the benefit as a continuation under 37 C.F.R. 1.53(b) of U.S. patentapplication Ser. No. 15/135,112, filed Apr. 21, 2016, now U.S. Pat. No.11,288,739, which claims the benefit of the filing date under 35 U.S.C.§ 119(e) of Provisional U.S. Patent Application Ser. No. 62/240,280,filed on Oct. 12, 2015, which are hereby incorporated by reference intheir entirety.

BACKGROUND

A financial instrument trading system, such as a futures exchange,referred to herein also as an “Exchange”, such as the Chicago MercantileExchange Inc. (CME), provides a contract market where financialproducts/instruments, for example futures and options on futures, aretraded. Futures is a term used to designate all contracts for thepurchase or sale of financial instruments or physical commodities forfuture delivery or cash settlement on a commodity futures exchange. Afutures contract is a legally binding agreement to buy or sell acommodity at a specified price at a predetermined future time, referredto as the expiration date or expiration month. An option is the right,but not the obligation, to sell or buy the underlying instrument (inthis case, a futures contract) at a specified price within a specifiedtime. The commodity to be delivered in fulfillment of the contract, oralternatively, the commodity, or other instrument/asset, for which thecash market price shall determine the final settlement price of thefutures contract, is known as the contract's underlying reference or“underlier.” The terms and conditions of each futures contract arestandardized as to the specification of the contract's underlyingreference commodity, the quality of such commodity, quantity, deliverydate, and means of contract settlement. Cash Settlement is a method ofsettling a futures contract whereby the party's effect final settlementwhen the contract expires by paying/receiving the loss/gain related tothe contract in cash, rather than by effecting physical sale andpurchase of the underlying reference commodity at a price determined bythe futures contract price.

Typically, the Exchange provides for a centralized “clearing house”through which all trades made must be confirmed, matched, and settledeach day until offset or delivered. The clearing house is an adjunct tothe Exchange, and may be an operating division thereof, which isresponsible for settling trading accounts, clearing trades, collectingand maintaining performance bond funds, regulating delivery, andreporting trading data. The essential role of the clearing house is tomitigate credit risk. Clearing is the procedure through which theClearing House becomes buyer to each seller of a futures contract, andseller to each buyer, also referred to as a novation, and assumesresponsibility for protecting buyers and sellers from financial loss dueto breach of contract, by assuring performance on each contract. Aclearing member is a firm qualified to clear trades through the ClearingHouse.

Current financial instrument trading systems allow customers to submitorders and receive confirmations, market data, and other informationelectronically via a network. These “electronic” marketplaces havelargely supplanted the pit based trading systems whereby the traders, ortheir representatives, all physically stand in a designated location,i.e. a trading pit, and trade with each other via oral and hand basedcommunication. In contrast to the pit based trading system wherelike-minded buyers and sellers can readily find each other to trade,electronic marketplaces must electronically “match” the orders placed bybuyers and sellers on behalf thereof. Electronic trading systems mayoffer a more efficient and transparent system of trading. Electronictrading systems may achieve more fair and equitable matching amongtraders as well as identify more opportunities to trade, therebyimproving market liquidity.

Customers such as market makers may place hundreds to thousands oforders with the Exchange covering multiple strikes for an instrument.These orders are generated by the customer, using data models which arebased on market data, and transmitted to the exchange quoting premiums.When the market changes, some or all of these orders may need to berecalculated and updated, typically all at once or in as little time aspossible, by, for example, sending in order modifications orcancellations to the exchange. The flood of information is taxing on theexchange hardware and also on customer's equipment as it may involvethousands to millions of message per second back and forth throughout aday.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an illustrative computer network system that may be usedto implement aspects of the disclosed embodiments.

FIG. 2 depicts an illustrative embodiment of a general computer systemfor use with the disclosed embodiments.

FIG. 3 depicts an example market order message management system forimplementing the disclosed embodiments

FIG. 4 depicts one embodiment of a system for triangulating options andfutures.

FIG. 5 depicts an example topology of a system for triangulating optionsand futures.

FIG. 6 depicts a flow chart showing exemplary operation of the system ofFIGS. 1 and 5 .

DETAILED DESCRIPTION

The disclosed embodiments allow for market participants to quote anorder for an options contract in implied volatility, as opposed toquoting by premium, and have the order implied into both the futuresmarket and the premium quoted options market. In existing systems,quotes may be received separately for each book and matched separately.Drawbacks in existing systems include massive communication bursts thatdegrade performance both on the exchange and customer sides, a lack ofliquidity in certain markets, and the inability to satisfy mitigationpossibilities. Triangulation solves these issues by moving part of themodeling to the exchange side, providing built-in mitigation, andincreasing liquidity between the different books.

The disclosed embodiments relate to systems and methods which match orotherwise allocate an incoming order to trade with “resting,” i.e.previously received but not yet matched (fully satisfied), orders. Inparticular, the disclosed embodiments relate to triangulation betweenfutures, premium option, and volatility order books allowing incomingorders to trade across all three books. Triangulation allows for ordersto quickly and efficiently imply between the books increasing marketliquidity. The disclosed embodiments further relate to storing acustomer's model and using the model to update the order books based onthe movement of the futures market; using the model saves time,communication bandwidth, and computing power. Triangulation furtherprovides automatic mitigation for volatility priced orders throughautomatic implication in the futures market.

A central limit order book (CLOB) may be a specialized order book thatthat matches customer orders (e.g. bids and offers). A CLOB may maintaina stack (ala resting orders) in that a customer can see multiple ordersfor and pricing for each product. Certain embodiments triangulate threesuch CLOB's—a futures CLOB (FUT CLOB), a premium quoted options CLOB(PQO CLOB), and a volatility quoted options CLOB (VQO CLOB). For eachinstrument offered by the exchange, there may exist these CLOB's (amongothers). In existing systems, each CLOB may be managed individually. Acustomer may place an order in the PQO CLOB or the VQO CLOB, or bothetc. Each of the books are matched by a matching engine separately. Incertain cases, an order may implied (synthetically copied and injected)from one CLOB to another related CLOB.

Different CLOB's may be related in that the underlying products arerelated, but the presentation, pricing, and/or satisfaction may bedifferent. For example, a product may be quoted using different pricingmodels or schemes. A customer may prefer to evaluate (and quote) aninstrument using different mechanisms or models. Two popular quotingmechanisms are premiums and volatility. When quoted, an order may bematched against it respective book either PQO CLOB (Premiums) or VQOCLOB (Volatility).

The PQO CLOB represents orders that are quoted in premiums. A premiummay be the price paid to acquire the option. Premiums may also bereferred to as the option price. Option prices are considered premiumsbecause the options themselves have no underlying value. The componentsof an option premium include its intrinsic value, its time value and theimplied volatility of the underlying asset. As the option nears itsexpiration date, the time value may edge closer and closer to $0, whilethe intrinsic value may closely represent the difference between theunderlying instrument's price and the strike price of the contract. Thestrike price may be defined as the price at which the holder of anoptions can buy (in the case of a call option) or sell (in the case of aput option) the underlying product when the option may be exercised. Thestrike price may also be referred to as the exercise price.

The VQO CLOB represents orders that are quoted in implied volatility.Volatility may be a statistical measurement of the degree of fluctuationof a market or security. Implied volatility may be the volatility asimplied by the market price of the option. The implied volatility may becalculated using an option pricing model, such as the Black model, inwhich a mathematical relationship between the volatility of theunderlying security and the price of its options has been established.Options on equities/cash may use a standard or custom model. Impliedvolatility may be the market's opinion of the volatility of the option'sunderlying security. The volatility of an option refers to how volatilethe price was/is expected to be. Using volatility, the price of theunderlying security, the market price of the option, the strike price ofthe option, the expiration date of the option, the interest rate, ifapplicable, and the dividend yield, if applicable, the premium price maybe determine

Implied volatility and premiums are related through use of optionspricing models. For example, using a pricing model, the impliedvolatility of an option may be backed out of the price of the option.Models such as Black, Black-Scholes, Whaley, Bjerksund, Merton, orcustomized models allow a trader or exchange to use implied volatilityto evaluate an options price or vice versa. Each customer, however, mayuse a different model to calculate volatility.

The Black model is a standard model used for evaluating Europeanoptions; Whaley is a standard model for US based options; options onequities/cash may use the standard Black-Scholes model. Black is used tocalculate a theoretical call price (ignoring dividends paid during thelife of the option) using the five key determinants of an option'sprice: underlying price, strike price, volatility, time to expiration,and short-term (risk free) interest rate. The original formula forcalculating the theoretical option price (OP) is as follows:

OP=SN(d ₁)−Xe ^(−n) N(d ₂)  Equation 1:

Where:

$\begin{matrix}{d_{1} = \frac{{\ln( \frac{S}{X} )} + {( {r + \frac{{\mathcal{v}}^{2}}{2}} )t}}{{\mathcal{v}}\sqrt{t}}} & {{Equation}2}\end{matrix}$ $\begin{matrix}{d_{2} = {d_{1} - {{\mathcal{v}}\sqrt{t}}}} & {{Equation}3}\end{matrix}$

The variables are: S=price, X=strike, t=time remaining until expiration,expressed as a percent of a year, r=current continuously compoundedrisk-free interest rate, v=volatility, ln=natural logarithm,N(x)=standard normal cumulative distribution function, and e=theexponential function.

The options pricing model may be solved for each variable. For example,a trader may start knowing the other variables and inputting avolatility to compute the premium. Likewise, the variables of an optionspricing model may be known (time to expiration, strike, price, interestrates) except for the volatility that the option is pricing in.Volatility may be backed out to understand the relative value of theoption's price. As such, volatility is a particularly preferred methodfor quoting options. A customer may calculate volatility using aproprietary equation and then submit an order quoting the impliedvolatility. This has many benefits, a key one being that sincevolatility is a measure of change over time, small movements in themarket do not effect it as much as premiums.

One of the downsides of using premium quoted options may be that as theFUT prices changes, the modeled option price OP may also changefrequently. Premiums are directly related to the FUT price (see Blackmodel above). Each time the FUT price ticks up or down (this happensconstantly), the premiums may be adjusted ever so slightly. Customersthat re-calculate their quotes as the FUT price moves may have to adjusteach order. For single orders this may not be a major issue as anexchange system may be setup to handle adjustments to orders. However,for every instrument, there may be 10, 100, or 1000s of strikes. Amarket maker may quote thousands of strike prices for each instrument.If and when the futures price ticks up or down, each and every singleorder would have to be recalculated and reentered (for each instrument,for each market maker). The volume of communications and messages mayoverload even a large pipeline. Implied volatility, however, changesless frequency than pricing. Large swings in the FUT price may affectvolatility, but smaller ticks up and down may not. As such, quoting involatility allows for fewer communications to be sent back and forthbetween traders and the exchange. An order may be quoted in volatilityand be valid for a length of time even while the futures market changes.

Although volatility quoted orders offer may benefits, some customers mayalways prefer to quote in premiums. As such, it may be preferable tomaintain an active premium quoted market. In order to maintain liquidityin the PQO market, orders that are quoted in volatility may beautomatically implied from the VQO market to the PQO market when thereis not a match in the VQO market. As mentioned above, small changes inthe FUT market may adjust the option price. It may be taxing for thecustomer to continuously adjust their premium quotes. In certainembodiments, a customer may supply an options pricing model to theexchange. The exchange stores and runs the model locally as the FUTprice changes. Instead of having the customer re-quote each order, theexchange may use the model to calculate the premiums. The exchange maythen imply an order into the PQO CLOB based on this calculation. As theFUT price changes, the implied quotes may be constantly re-quoted. Thismay be another benefit of triangulation with the FUT market. Locking theFutures market when these orders are being calculated and re-quoted mayallow for the exchange to recalculate the quotes without the underlyingvariables changing during the calculation. Additionally, because thismay be done within the exchange environment, there may be less of needto receive and produce the massive amounts of communications that arepresent in existing systems.

Volatility quoted options are conventionally hedged. As with mosttransactions, volatility quoted orders carry risk. For example, for anaked call, the theoretical risk may be infinite. The customer may beresponsible for the difference between the strike price and the amountthe instrument moves above this price. Because there is not a limit tohow high a price can trade, the potential loss may be infinite. In orderto protect themselves, traders may generally always hedge orders byusing an opposite-side-of-the-market futures trade. Together, the optionand the future comprise a delta-neutral option-future combination. Inexisting systems, the futures order may be entered separately from thevolatility quoted order. Certain embodiment including triangulation withthe futures market allow the hedge transaction to proceed automatically.When an order is quoted in volatility, the order may also be impliedinto the futures market.

In certain embodiments, the system allows traders to place orders totrade options contracts by specifying those orders based on volatilityor on price. The orders are trading against separate order books withseparate match engines, for example a VQO book and a PQO book.Implication may be used between the VQO book and PQO book to provideliquidity. Hedging, via implication, into the underlying Futures orderbook may also be provided to automatically trade the requisite futurescontracts to hedge a particular options trade.

When trading options contracts by volatility, a trader may provide theirquoting model to the exchange. The exchange may normalize the model andstore the model with alternative models from other traders. Once aninitial order to trade a VQO is placed, the exchange automaticallymaintains/updates the order based on changes in the underlying futuresmarket and the trader's stored quoting model. Where a trader has 1000'sof orders, the automatically updating alleviates the trader from havingto maintain each of the 1000's of orders, such as by sending in 1000'sof order modifications/cancelations, etc., as the market changes.Instead, the Exchange takes care of the updating and maintenance. Oncethe VQO orders have been updated due to a market change, those updates,via implication, are carried into/reflected in the PQO and underlyingfutures markets.

While the disclosed embodiments may be discussed in relation to futuresand/or options on futures trading, it may be appreciated that they maybe applicable to any equity, options or futures trading system, e.g.,exchange, Electronic Communication Network (“ECN”), Alternative TradingSystem (“ATS”), or Swap Execution Facility (“SEF”), or market nowavailable or later developed, e.g. cash, Futures, etc., as well as anyinstrument traded thereon. It may be appreciated that a tradingenvironment, such as a futures exchange as described herein, implementsone or more economic markets where rights and obligations may be traded.As such, a trading environment may be characterized by a need tomaintain market integrity, transparency, predictability, fair/equitableaccess and participant expectations with respect thereto. For example,an exchange must respond to inputs, such as trade orders, cancellation,etc., in a manner as expected by the market participants, such as basedon market data, e.g. prices, available counter-orders, etc., to providean expected level of certainty that transactions may occur in aconsistent and predictable manner and without unknown or unascertainablerisks. In addition, it may be appreciated that electronic tradingsystems further impose additional expectations and demands by marketparticipants as to transaction processing speed, latency, capacity andresponse time, while creating additional complexities relating thereto.Accordingly, as will be described, the disclosed embodiments may furtherinclude functionality to ensure that the expectations of marketparticipant are met, e.g. that transactional integrity and efficiencyare maintained.

As was discussed above, electronic trading systems ideally attempt tooffer an objective, efficient, fair and balanced market where marketprices reflect a true consensus of the value of products traded amongthe market participants, where the intentional or unintentionalinfluence of human interaction may be minimized if not eliminated, andwhere unfair or inequitable advantages with respect to informationaccess are minimized if not eliminated. The current systems ideallyattempt to increase liquidity, decrease message volume, and increasematching performance.

An exchange provides one or more markets for the purchase and sale ofvarious types of products including financial instruments such asstocks, bonds, futures contracts, options, currency, cash, and othersimilar instruments. Agricultural products and commodities are alsoexamples of products traded on such exchanges. A futures contract is aproduct that is a contract for the future delivery of another financialinstrument such as a quantity of grains, metals, oils, bonds, currency,or cash. Generally, each exchange establishes a specification for eachmarket provided thereby that defines at least the product traded in themarket, minimum quantities that must be traded, and minimum changes inprice (e.g., tick size). For some types of products (e.g., futures oroptions), the specification further defines a quantity of the underlyingproduct represented by one unit (or lot) of the product, and deliveryand expiration dates. As will be described, the Exchange may furtherdefine the matching algorithm, or rules, by which incoming orders willbe matched/allocated to resting orders.

Some products on an exchange are traded in an open outcry environmentwhere the exchange provides a location for buyers and sellers to meetand negotiate a price for a quantity of a product. Other products aretraded on an electronic trading platform (e.g., an electronic exchange),also referred to herein as a trading platform, electronic tradingsystem, trading host or Exchange Computer System, where marketparticipants, e.g. traders, use software to send orders to the tradingplatform. The order identifies the product, the quantity of the productthe trader wishes to trade, a price at which the trader wishes to tradethe product, and a direction of the order (i.e., whether the order is abid, i.e. an offer to buy, or an ask, i.e. an offer to sell). It will beappreciated that there may be other order types or messages that traderscan send including requests to modify or cancel a previously submittedorder.

In particular, electronic trading of financial instruments, such asfutures contracts, may be conducted by market participants sendingorders, such as to buy or sell one or more futures contracts, inelectronic form to the Exchange. These electronically submitted ordersto buy and sell are then matched, if possible, by the Exchange, i.e. bythe Exchange's matching engine, to execute a trade. Outstanding(unmatched, wholly unsatisfied/unfilled or partiallysatisfied/filled/completed) orders are maintained in one or more datastructures or databases referred to as “order books,” such orders beingreferred to as “resting,” and made visible, i.e., their availability fortrading is advertised, to the market participants through electronicnotifications/broadcasts, referred to as market data feeds. An orderbook/data structure may be typically maintained for each product, e.g.instrument, traded on the electronic trading system and generallydefines or otherwise represents the state of the market for thatproduct, i.e. the current prices at which the market participants arewilling buy or sell that product. As such, as used herein, an order bookfor a product may also be referred to as a market for that product. ACLOB (Central Limit Order Book) may be a type of transparent order booksystem that matches customer orders.

In the exemplary embodiments, all transactions for a particular marketmay be ultimately received at the electronic trading system via one ormore points of entry, e.g. one or more communications interfaces, atwhich the disclosed embodiments apply determinism, which as describedmay be at the point where matching occurs, e.g. at each match engine(where there may be multiple match engines, each for a givenproduct/market, or moved away from the point where matching occurs andcloser to the point where the electronic trading system first becomes“aware” of the incoming transaction, such as the point where transactionmessages, e.g. orders, ingress the electronic trading system. Generally,the terms “determinism” or “transactional determinism” may refer to theprocessing, or the appearance thereof, of orders in accordance withdefined business rules. Accordingly, as used herein, the point ofdeterminism may be the point at which the electronic trading systemascribes an ordering to incoming transactions/orders relative to otherincoming transactions/orders such that the ordering may be factored intothe subsequent processing, e.g. matching, of those transactions/ordersas will be described. See U.S. patent application Ser. No. 14/074,675,filed on Nov. 7, 2013, published as U.S. Patent Application PublicationNo. 2015/0127516, entitled “TRANSACTIONALLY DETERMINISTIC HIGH SPEEDFINANCIAL EXCHANGE HAVING IMPROVED, EFFICIENCY, COMMUNICATION,CUSTOMIZATION, PERFORMANCE, ACCESS, TRADING OPPORTUNITIES, CREDITCONTROLS, AND FAULT TOLERANCE”, incorporated by reference herein.

Upon receipt of an incoming order to trade in a particular financialinstrument, whether for a single component financial instrument, e.g. asingle futures contract, or for multiple component financialinstruments, e.g. a combination contract such as a spread contract, amatch engine, as will be described in detail below, will attempt toidentify a previously received but unsatisfied order counter thereto,i.e. for the opposite transaction (buy or sell) in the same financialinstrument at the same or better price (but not necessarily for the samequantity unless, for example, either order specifies a condition that itmust be entirely filled or not at all). Previously received butunsatisfied orders, i.e. orders which either did not match with acounter order when they were received or their quantity was onlypartially satisfied, referred to as a partial fill, are maintained bythe electronic trading system in an order book database/data structureto await the subsequent arrival of matching orders or the occurrence ofother conditions which may cause the order to be removed from the orderbook.

If the match engine identifies one or more suitable previously receivedbut unsatisfied counter orders, they, and the incoming order, arematched to execute a trade there between to at least partially satisfythe quantities of one or both the incoming order or the identifiedorders. If there remains any residual unsatisfied quantity of theidentified one or more orders, those orders are left on the order bookwith their remaining quantity to await a subsequent suitable counterorder, i.e. to rest. If the match engine does not identify a suitablepreviously received but unsatisfied counter order, or the one or moreidentified suitable previously received but unsatisfied counter ordersare for a lesser quantity than the incoming order, the incoming order isplaced on the order book, referred to as “resting”, with original orremaining unsatisfied quantity, to await a subsequently receivedsuitable order counter thereto. The match engine then generates matchevent data reflecting the result of this matching process. Othercomponents of the electronic trading system, as will be described, thengenerate the respective order acknowledgment and market data messagesand transmit those messages to the market participants.

As was described above, the financial instruments which are the subjectof the orders to trade, may include one or more component financialinstruments. While each financial instrument may have its own orderbook, i.e. market, in which it may be traded, in certain embodiments,each financial instrument, may be listed in alternative related orderbooks. Accordingly, when an order for a financial instrument isreceived, it may be matched against a suitable counter order in its ownorder book or, possibly, against other suitable counter orders in therelated order books. For example, an order for a volatility optionsquoted contract may be matched against another suitable order for thatcontract. However, it may also be matched against suitable separatecounter orders for the premium quoted options or futures found in theirrespective CLOB's (both the premium quoted and the volatility quotedbeing related to another using a pricing model). This is referred to as“implication” where a given order for a financial instrument may bematched via a combination of suitable counter orders for instrumentswhich share common, or otherwise interdependent, financial variables.

The order for a particular instrument actually received from a marketparticipant, whether it comprises one or more component financialinstruments, is referred to as a “real” or “outright” order, or simplyas an outright. The one or more orders which must be synthesized intoorder books other than the order book for the outright order in order tocreate matches therein, are referred to as “implied” orders. Uponreceipt of an incoming order, the identification or derivation ofsuitable implied orders which would allow at least a partial trade ofthe incoming outright order to be executed is referred to as “impliedmatching”, the identified orders being referred to as an “impliedmatch.” There may be numerous different implied matches identified whichwould allow the incoming order to be at least partially matched andmechanisms may be provided to arbitrate among them, such as by pickingthe implied match comprising the least number of synthesized orders.

Upon receipt of an incoming order, or thereafter, the identification orderivation of a combination of one or more suitable counter orders whichhave not actually been received but if they were received, would allowat least a partial trade of the incoming order to be executed, isreferred to as an “implied opportunity.” As with implied matches, theremay be numerous implied opportunities identified for a given incomingorder. Implied opportunities are advertised to the market participants,such as via suitable synthetic orders, e.g. counter to the desiredorder, being placed on the respective order books to rest (or give theappearance that there is an order resting) and presented via the marketdata feed to appear available to trade in order to solicit the desiredorders from the market participants. There may be numerous impliedopportunities, the submission thereof, would allow the incoming order tobe at least partially matched.

In general, advertising implied opportunities will encourage traders toenter the opposing orders to trade with them. The more impliedopportunities that the match engine of an electronic trading system cancalculate/derive, the greater this encouragement will be and the morethe Exchange will benefit from increased transaction volume. However,identifying implied opportunities may be computationally intensive. In ahigh performance trading system where low transaction latency isimportant, it may be important to identify and advertise impliedopportunities quickly so as to improve or maintain market participantinterest and/or market liquidity.

In certain embodiments, the exchange system uses implied matching andimplied opportunities to triangulate between three CLOB's, e.g. VQO CLOB(Volatility), PQO CLOB (Premium), and FUT CLOB (Futures). The mechanismsof the implied matching are discussed below and illustrated by scenariosin Appendix A which is incorporated by reference herein in its entirety.In certain embodiments, a customer quotes VQO. The exchange systemimplies an order into the PQO CLOB and/or FUT CLOB, increasing bothliquidity and providing a mechanism to mitigate risk. Alternativemethods of implying orders are also contemplated. For example, theexchange system may create an implied calendar spread. The standardcalendar spread (SP) consists of two instruments within the same productgroup having different maturity months. Buy (1) calendar means: Buy (1)front month leg and Sell (1) back month leg (+1:−1 ratio).

A futures calendar spread may be composed of a long or short position inthe futures in one expiration cycle and a position with the oppositesign in a different expiration. Example: short one contract of Februarynatural gas and buy one contract of April natural gas. The profit orloss to a futures calendar position depends on changes in the prices ofthe contracts, and because the two contracts are on the same underlyingasset the profitability of the spread will depend more specifically onchanges in the term structure of the futures curve. In this example, ifthe prices of both contracts decline, but the February contract declinesmore, the position will make a profit.

An options calendar spread may be composed of two contracts with thesame underlying asset, the same right (call or put), the same strikeprice, and different expiration months. This sort of calendar spread istypically opened at the same time by buying one option and selling theother, e.g. by selling the at the money call in the first expirationcycle and buying the at the money call in the second expiration cycle.While a futures calendar is affected by changes in the prices of thefutures contracts, an options calendar is affected not just by pricechanges but also by changes in implied volatility. In fact, a shortcalendar (sell the longer dated option and buy the nearer one) is one ofthe simpler ways to gain long volatility exposure using options.

Receiving a bid for the implied book may create multiple orders in theexplicit books. In certain embodiments, the exchange system (and thematch engine(s)) are configured to imply across more than three orderbooks. As illustrated in the calendar spread scenarios, the exchangesystem may create implied books or imply across spreads.

Matching, which is a function typically performed by the Exchange, is aprocess, for a given order which specifies a desire to buy or sell aquantity of a particular instrument at a particular price, ofseeking/identifying one or more wholly or partially, with respect toquantity, satisfying counter orders thereto, e.g. a sell counter to anorder to buy, or vice versa, for the same instrument at the same, orsometimes better, price (but not necessarily the same quantity), whichare then paired for execution to complete a trade between the respectivemarket participants (via the Exchange) and at least partially satisfythe desired quantity of one or both of the order and/or the counterorder, with any residual unsatisfied quantity left to await anothersuitable counter order, referred to as “resting.”

The Exchange Computer System, as will be described below, monitorsincoming orders received thereby and attempts to identify, i.e., matchor allocate, as will be described in more detail below, one or morepreviously received, but not yet matched, orders, i.e. limit orders tobuy or sell a given quantity at a given price, referred to as “resting”orders, stored in an order book database, wherein each identified orderis contra to the incoming order and has a favorable price relative tothe incoming order. An incoming order may be an “aggressor” order, i.e.,a market order to sell a given quantity at whatever may be the currentresting bid order price(s) or a market order to buy a given quantity atwhatever may be the current resting ask order price(s). An incomingorder may be a “market making” order, i.e. a market order to buy or sellat a price for which there are currently no resting orders. Inparticular, if the incoming order is a bid, i.e. an offer to buy, thenthe identified order(s) will be an ask, i.e. an offer to sell, at aprice that is identical to or higher than the bid price. Similarly, ifthe incoming order is an ask, i.e. an offer to sell, the identifiedorder(s) will be a bid, i.e. an offer to buy, at a price that isidentical to or lower than the offer price.

Upon identification (matching) of a contra order(s), a minimum of thequantities associated with the identified order and the incoming orderis matched and that quantity of each of the identified and incomingorders become two halves of a matched trade that is sent to aclearinghouse. The Exchange Computer System considers each identifiedorder in this manner until either all of the identified orders have beenconsidered or all of the quantity associated with the incoming order hasbeen matched, i.e. the order has been filled. If any quantity of theincoming order remains, an entry may be created in the order bookdatabase and information regarding the incoming order is recordedtherein, i.e. a resting order is placed on the order book for theremaining quantity to await a subsequent incoming order counter thereto.

Volatility quoted orders are conventionally hedged. As with mosttransactions, volatility quoted orders carry risk. For example, for anaked call, the theoretical risk may be infinite. The customer may beresponsible for the difference between the strike price and the amountthe instrument moves above this price. Because there isn't a limit tohow high a price can trade, the potential loss may be infinite. In orderto protect themselves, orders are generally if not always hedged byusing an opposite-side-of-the-market futures trade. Together, the optionand the future comprise a delta-neutral option-future combination. Inexisting systems, the futures order may be made separately from theVolatility quoting order. A customer may have to anticipate the FUT CLOBin order to determine how to mitigate risk. This has multiple effects.The necessity that a second trade be made creates double the messagevolume as a single trade. The second order may be initiated by thecustomer, which means at least some latency in the time to calculate andtransmit the order. The second order is also not guaranteed to match.Matching the second order in the futures market will necessarily dependon the current orders resting in the FUT CLOB and if they are sufficientto offer mitigation.

In certain embodiments, with triangulation, mitigation is handledautomatically. When a VQO or PQO is matched, the match engine may alsoattempt to match an opposite-side-of-the-market futures trade. The matchengine(s) has direct access to the FUT market and may be able todetermine the availability of futures to mitigate the risk involved withthe volatility or premium quoted orders. The match engine may be able todetermine what size bid to fill by being able to determine the size ofthe available FUT market. A customer or trader may place orders muchlarger than possible in the past with the knowledge that the order willbe automatically hedged.

Traders access the markets on a trading platform using trading softwarethat receives and displays at least a portion of the order book for amarket, i.e. at least a portion of the currently resting orders, enablesa trader to provide parameters for an order for the product traded inthe market, and transmits the order to the Exchange Computer System. Thetrading software typically includes a graphical user interface todisplay at least a price and quantity of some of the entries in theorder book associated with the market. The number of entries of theorder book displayed is generally preconfigured by the trading software,limited by the Exchange Computer System, or customized by the user. Somegraphical user interfaces display order books of multiple markets of oneor more trading platforms. The trader may be an individual who trades onhis/her behalf, a broker trading on behalf of another person or entity,a group, or an entity. Furthermore, the trader may be a system thatautomatically generates and submits orders.

If the Exchange Computer System identifies that an incoming market ordermay be filled by a combination of multiple resting orders, e.g. theresting order at the best price does only partially fills the incomingorder, the Exchange Computer System may allocate the remaining quantityof the incoming, i.e. that which was not filled by the resting order atthe best price, among such identified orders in accordance withprioritization and allocation rules/algorithms, referred to as“allocation algorithms” or “matching algorithms,” as, for example, maybe defined in the specification of the particular financial product ordefined by the Exchange for multiple financial products. Similarly, ifthe Exchange Computer System identifies multiple orders contra to theincoming limit order and that have an identical price which may befavorable to the price of the incoming order, i.e. the price is equal toor better, e.g. lower if the incoming order is a buy or higher if theincoming order is a sell, than the price of the incoming order, theExchange Computer System may allocate the quantity of the incoming orderamong such identified orders in accordance with the matching algorithmsas, for example, may be defined in the specification of the particularfinancial product or defined by the Exchange for multiple financialproducts.

In certain embodiments, the allocation or matching algorithms may takeinto consideration if the order is “real” (explicit) or implicit). Asdiscussed below, these algorithms may include multiple strategies thatmay be presented transparently to the customers so that they may beaware of how the match engine operates. Since implied orders aresynthetically created (and not received), they may not correspond to theFIFO strategy. In such a scenario, the implied orders may be treated asjunior to the real orders. Alternatively, the match engine may treat theimplied order as an extension of the original real order and give theimplied order the same time priority. These scenarios and others aredescribed below.

As was noted above, an Exchange must respond to inputs, such as traderorders, cancellation, etc., in a manner as expected by the marketparticipants, such as based on market data, e.g. prices, availablecounter-orders, etc., to provide an expected level of certainty thattransactions will occur in a consistent and predictable manner andwithout unknown or unascertainable risks. Accordingly, the method bywhich incoming orders are matched with resting orders must be defined sothat market participants have an expectation of what the result will bewhen they place an order or have resting orders and incoming order isreceived, even if the expected result is, in fact, at least partiallyunpredictable due to some component of the process being random orarbitrary or due to market participants having imperfect or less thanall information, e.g. unknown position of an order in an order book.Typically, the Exchange defines the matching/allocation algorithm thatwill be used for a particular financial product, with or without inputfrom the market participants. Once defined for a particular product, thematching/allocation algorithm is typically not altered, except inlimited circumstance, such as to correct errors or improve operation, soas not to disrupt trader expectations. It will be appreciated thatdifferent products offered by a particular Exchange may use differentmatching algorithms.

For example, a first-in/first-out (FIFO) matching algorithm, alsoreferred to as a “Price Time” algorithm, considers each identified ordersequentially in accordance with when the identified order was received.The quantity of the incoming order is matched to the quantity of theidentified order at the best price received earliest, then quantities ofthe next earliest best price orders, and so on until the quantity of theincoming order is exhausted. Some product specifications define the useof a pro-rata matching algorithm, wherein a quantity of an incomingorder is allocated to each of plurality of identified ordersproportionally. Some Exchange Computer Systems provide a priority tocertain standing orders in particular markets. An example of such anorder is the first order that improves a price (i.e., improves themarket) for the product during a trading session. To be given priority,the trading platform may require that the quantity associated with theorder is at least a minimum quantity. Further, some Exchange ComputerSystems cap the quantity of an incoming order that is allocated to astanding order on the basis of a priority for certain markets. Inaddition, some Exchange Computer Systems may give a preference to orderssubmitted by a trader who is designated as a market maker for theproduct. Other Exchange Computer Systems may use other criteria todetermine whether orders submitted by a particular trader are given apreference. Typically, when the Exchange Computer System allocates aquantity of an incoming order to a plurality of identified orders at thesame price, the trading host allocates a quantity of the incoming orderto any orders that have been given priority. The Exchange ComputerSystem thereafter allocates any remaining quantity of the incoming orderto orders submitted by traders designated to have a preference, and thenallocates any still remaining quantity of the incoming order using theFIFO or pro-rata algorithms. Pro-rata algorithms used in some marketsmay require that an allocation provided to a particular order inaccordance with the pro-rata algorithm must meet at least a minimumallocation quantity. Any orders that do not meet or exceed the minimumallocation quantity are allocated to on a FIFO basis after the pro-rataallocation (if any quantity of the incoming order remains). Moreinformation regarding order allocation may be found in U.S. Pat. No.7,853,499, the entirety of which is incorporated by reference herein.

Other examples of matching algorithms which may be defined forallocation of orders of a particular financial product include:

-   -   Price Explicit Time    -   Order Level Pro Rata    -   Order Level Priority Pro Rata    -   Preference Price Explicit Time    -   Preference Order Level Pro Rata    -   Preference Order Level Priority Pro Rata    -   Threshold Pro-Rata    -   Priority Threshold Pro-Rata    -   Preference Threshold Pro-Rata    -   Priority Preference Threshold Pro-Rata    -   Split Price-Time Pro-Rata

For example, the Price Explicit Time trading policy is based on thebasic Price Time trading policy with Explicit Orders having priorityover Implied Orders at the same price level. The order of traded volumeallocation at a single price level may therefore be:

-   -   Explicit order with oldest timestamp first. Followed by    -   Any remaining explicit orders in timestamp sequence (First In,        First Out—FIFO) next. Followed by    -   Implied order with oldest timestamp next. Followed by    -   Any remaining implied orders in timestamp sequence (FIFO).

In Order Level Pro Rata, also referred to as Price Pro Rata, priority isgiven to orders at the best price (highest for a bid, lowest for anoffer). If there are several orders at this best price, equal priorityis given to every order at this price and incoming business is dividedamong these orders in proportion to their order size. The Pro Ratasequence of events is:

-   -   1. Extract all potential matching orders at best price from the        order book into a list.    -   2. Sort the list by order size, largest order size first. If        equal order sizes, oldest timestamp first. This is the matching        list.    -   3. Find the ‘Matching order size, which is the total size of all        the orders in the matching list.    -   4. Find the ‘tradable volume’, which is the smallest of the        matching volume and the volume left to trade on the incoming        order.    -   5. Allocate volume to each order in the matching list in turn,        starting at the beginning of the list. If all the tradable        volume gets used up, orders near the end of the list may not get        allocation.    -   6. The amount of volume to allocate to each order is given by        the formula: (Order volume/Matching volume)*Tradable volume        -   The result is rounded down (for example, 21.99999999            becomes 21) unless the result is less than 1, when it            becomes 1.    -   7. If tradable volume remains when the last order in the list        had been allocated to, return to step 3.        -   Note: The matching list is not re-sorted, even though the            volume has changed. The order which originally had the            largest volume is still at the beginning of the list.    -   8. If there is still volume left to trade on the incoming order,        repeat the entire algorithm at the next price level.

Order Level Priority Pro Rata, also referred to as Threshold Pro Rata,is similar to the Price (or ‘Vanilla’) Pro Rata algorithm but has avolume threshold defined. Any pro rata allocation below the thresholdwill be rounded down to 0. The initial pass of volume allocation iscarried out in using pro rata; the second pass of volume allocation iscarried out using Price Explicit Time. The Threshold Pro Rata sequenceof events is:

-   -   1. Extract all potential matching orders at best price from the        order book into a list.    -   2. Sort the list by explicit time priority, oldest timestamp        first. This is the matching list.    -   3. Find the ‘Matching volume’, which is the total volume of all        the orders in the matching list.    -   4. Find the ‘tradable volume’, which is the smallest of the        matching volume and the volume left to trade on the incoming        order.    -   5. Allocate volume to each order in the matching list in turn,        starting at the beginning of the list.    -   6. The amount of volume to allocate to each order is given by        the formula: (Order volume/Matching volume)*Tradable volume        -   The result is rounded down to the nearest lot (for example,            21.99999999 becomes 21) unless the result is less than the            defined threshold in which case it is rounded down to 0.    -   7. If tradable volume remains when the last order in the list        had been allocated to, the remaining volume is allocated in time        priority to the matching list.    -   8. If there is still volume left to trade on the incoming order,        repeat the entire algorithm at the next price level.

In the Split Price Time Pro-Rata algorithms, a Price Time Percentageparameter is defined. This percentage of the matching volume at eachprice is allocated by the Price Explicit Time algorithm and theremainder is allocated by the Threshold Pro-Rata algorithm. There arefour variants of this algorithm, with and without Priority and/orPreference. The Price Time Percentage parameter is an integer between 1and 99. (A percentage of zero would be equivalent to using therespective existing Threshold Pro-Rata algorithm, and a percentage of100 would be equivalent to using the respective existing Price Timealgorithm). The Price Time Volume will be the residual incoming volume,after any priority and/or Preference allocation has been made,multiplied by the Price Time Percentage. Fractional parts will berounded up, so the Price Time Volume will always be at least 1 lot andmay be the entire incoming volume. The Price Time Volume is allocated toresting orders in strict time priority. Any remaining incoming volumeafter the Price Time Volume has been allocated will be allocatedaccording to the respective Threshold Pro-Rata algorithm. The sequenceof allocation, at each price level, is therefore:

-   -   1. Priority order, if applicable    -   2. Preference allocation, if applicable    -   3. Price Time allocation of the configured percentage of        incoming volume    -   4. Threshold Pro-Rata allocation of any remaining incoming        volume    -   5. Final allocation of any leftover lots in time sequence.        -   Any resting order may receive multiple allocations from the            various stages of the algorithm.

It will be appreciated that there may be other allocation algorithms,including combinations of algorithms, now available or later developed,which may be utilized with the disclosed embodiments, and all suchalgorithms are contemplated herein.

One exemplary system for matching is described in U.S. patentapplication Ser. No. 13/534,499, filed on Jun. 27, 2012, entitled“MULTIPLE TRADE MATCHING ALGORITHMS,” published as U.S. PatentApplication Publication No. 2014/0006243 A1, incorporated by referenceherein, discloses an adaptive match engine which draws upon differentmatching algorithms, e.g. the rules which dictate how a given ordershould be allocated among qualifying resting orders, depending uponmarket conditions, to improve the operation of the market. For example,for a financial product, such as a futures contract, having a futureexpiration date, the match engine may match incoming orders according toone algorithm when the remaining time to expiration is above athreshold, recognizing that during this portion of the life of thecontract, the market for this product is likely to have high volatility.However, as the remaining time to expiration decreases, volatility maydecrease. Accordingly, when the remaining time to expiration falls belowthe threshold, the match engine switches to a different match algorithmwhich may be designed to encourage trading relative to the decliningtrading volatility. Thereby, by conditionally switching among matchingalgorithms within the same financial product, as will be described, thedisclosed match engine automatically adapts to the changing marketconditions of a financial product, e.g. a limited life product, in anon-preferential manner, maintaining fair order allocation whileimproving market liquidity, e.g., over the life of the product.

In one implementation, this trading system may evaluate marketconditions on a daily basis and, based thereon, change the matchingalgorithm between daily trading sessions, i.e. when the market isclosed, such that when the market reopens, a new trading algorithm is ineffect for the particular product. As will be described, the disclosedembodiments may facilitate more frequent changes to the matchingalgorithms so as to dynamically adapt to changing market conditions,e.g. intra-day changes, and even intra-order matching changes. It willbe further appreciated that hybrid matching algorithms, which match partof an order using one algorithm and another part of the order using adifferent algorithm, may also be used.

With respect to incoming orders, some traders, such as automated and/oralgorithmic traders, attempt to respond to market events, such as tocapitalize upon a mispriced resting order or other market inefficiency,as quickly as possible. This may result in penalizing the trader whomakes an errant trade, or whose underlying trading motivations havechanged, and who cannot otherwise modify or cancel their order fasterthan other traders can submit trades there against. It may consideredthat an electronic trading system that rewards the trader who submitstheir order first creates an incentive to either invest substantialcapital in faster trading systems, participate in the marketsubstantially to capitalize on opportunities (aggressor side/lower risktrading) as opposed to creating new opportunities (market making/higherrisk trading), modify existing systems to streamline business logic atthe cost of trade quality, or reduce one's activities and exposure inthe market. The result may be a lesser quality market and/or reducedtransaction volume, and corresponding thereto, reduced fees to theExchange.

With respect to resting orders, allocation/matching suitable restingorders to match against an incoming order can be performed, as describedabove, in many different ways. Generally, it will be appreciated thatallocation/matching algorithms are only needed when the incoming orderquantity is less than the total quantity of the suitable resting ordersas, only in this situation, is it necessary to decide which restingorder(s) will not be fully satisfied, which trader(s) may not get theirorders filled. It can be seen from the above descriptions of thematching/allocation algorithms that they fall generally into threecategories: time priority/first-in-first-out (“FIFO”), pro rata, or ahybrid of FIFO and pro rata.

FIFO generally rewards the first trader to place an order at aparticular price and maintains this reward indefinitely. So if a traderis the first to place an order at price X, no matter how long that orderrests and no matter how many orders may follow at the same price, assoon as a suitable incoming order is received, that first trader may bematched first. This “first mover” system may commit other traders topositions in the queue after the first move traders. Furthermore, whileit may be beneficial to give priority to a trader who is first to placean order at a given price because that trader is, in effect, taking arisk, the longer that the trader's order rests, the less beneficial itmay be. For instance, it could deter other traders from adding liquidityto the marketplace at that price because they know the first mover (andpotentially others) already occupies the front of the queue.

With a pro rata allocation, incoming orders are effectively split amongsuitable resting orders. This provides a sense of fairness in thateveryone may get some of their order filled. However, a trader who tooka risk by being first to place an order (a “market turning” order) at aprice may end up having to share an incoming order with a much latersubmitted order. Furthermore, as a pro rata allocation distributes theincoming order according to a proportion based on the resting orderquantities, traders may place orders for large quantities, which theyare willing to trade but may not necessarily want to trade, in order toincrease the proportion of an incoming order that they may receive. Thisresults in an escalation of quantities on the order book and exposes atrader to a risk that someone may trade against one of these orders andsubject the trader to a larger trade than they intended. In the typicalcase, once an incoming order is allocated against these large restingorders, the traders subsequently cancel the remaining resting quantitywhich may frustrate other traders. Accordingly, as FIFO and pro rataboth have benefits and problems, Exchanges may try to use hybridallocation/matching algorithms which attempt to balance these benefitsand problems by combining FIFO and pro rata in some manner. However,hybrid systems define conditions or fixed rules to determine when FIFOshould be used and when pro rata should be used. For example, a fixedpercentage of an incoming order may be allocated using a FIFO mechanismwith the remainder being allocated pro rata. The hybrid system discussedabove switches between FIFO and pro rata based on a condition of themarket.

An exemplary trading network environment for implementing tradingsystems and methods is shown in FIG. 1 . An exchange computer system 100receives messages that include orders and transmits market data relatedto orders and trades to users, such as via wide area network 126 and/orlocal area network 124 and computer devices 114, 116, 118, 120 and 122,as will be described below, coupled with the exchange computer system100.

Herein, the phrase “coupled with” is defined to mean directly connectedto or indirectly connected through one or more intermediate components.Such intermediate components may include both hardware and softwarebased components. Further, to clarify the use in the pending claims andto hereby provide notice to the public, the phrases “at least one of<A>, <B>, . . . and <N>” or “at least one of <A>, <B>, . . . <N>, orcombinations thereof” are defined by the Applicant in the broadestsense, superseding any other implied definitions here before orhereinafter unless expressly asserted by the Applicant to the contrary,to mean one or more elements selected from the group comprising A, B, .. . and N, that is to say, any combination of one or more of theelements A, B, . . . or N including any one element alone or incombination with one or more of the other elements which may alsoinclude, in combination, additional elements not listed.

The exchange computer system 100 may be implemented with one or moremainframe, desktop or other computers, such as the example computer 200described below with respect to FIG. 2 . A user database 102 may beprovided which includes information identifying traders and other usersof exchange computer system 100, such as account numbers or identifiers,user names and passwords. An account data module 104 may be providedwhich may process account information that may be used during trades. Amatch engine module 106 may be included to match bid and offer pricesand may be implemented with software that executes one or morealgorithms for matching bids and offers. A match engine module/matchengine/match processor 106 may be a hardware matching processor which ispart of a transaction processing system. A data transaction processingsystem in which data items are transacted by a hardware matchingprocessor that matches electronic data transaction request messages forthe same one of the data items based on multiple transaction parametersfrom different client computers over a data communication network. Atrade database 108 may be included to store information identifyingtrades and descriptions of trades. In particular, a trade database maystore information identifying the time that a trade took place and thecontract price. An order book module 110 may be included to compute orotherwise determine current bid and offer prices, e.g., in a continuousauction market, or also operate as an order accumulation buffer for abatch auction market.

A market data module 112 may be included to collect market data andprepare the data for transmission to users. A risk management module 134may be included to compute and determine a user's risk utilization inrelation to the user's defined risk thresholds. An order processingmodule 136 may be included to decompose delta based and bulk order typesfor processing by the order book module 110 and/or match engine module106. A message management module 140 may be included to, among otherthings, receive, and extract orders from, electronic messages as isindicated with one or more aspects of the disclosed embodiments. Amarket condition prediction module 142 may be included to generatetransaction processing system latency estimates, as discussed herein. Itshould be appreciated that concurrent processing limits may be definedby or imposed separately or in combination, as was described above, onone or more of the trading system components, including the userdatabase 102, the account data module 104, the match engine module 106,the trade database 108, the order book module 110, the market datamodule 112, the risk management module 134, the order processing module136, the message management module 140, the market condition predictionmodule 142, or other component of the exchange computer system 100.

In an embodiment, the message management module 140, as coupled with theorder book module 110, may be configured for receiving a plurality ofelectronic messages, each of the plurality of messages having anassociated action to be executed within a designated period of timehaving a beginning time and an ending time, wherein at least oneelectronic message of the plurality of electronic messages comprisesdata representative of a particular time between the beginning and endof the period of time at which the action associated with the at leastone electronic message is to be executed. The exchange computer system100 may then be further configured to execute the action associated withthe at least one temporally specific message at the particular time.

The message management module 140 may define a point of ingress into theexchange computer system 100 where messages are ordered and consideredto be received by the system. This may be considered a point ofdeterminism in the exchange computer system 100 that defines theearliest point where the system can ascribe an order of receipt toarriving messages. The point of determinism may or may not be at or nearthe demarcation point between the exchange computer system 100 and apublic/internet network infrastructure.

One skilled in the art will appreciate that one or more modulesdescribed herein may be implemented using, among other things, atangible computer-readable medium comprising computer-executableinstructions (e.g., executable software code). Alternatively, modulesmay be implemented as software code, firmware code, hardware, and/or acombination of the aforementioned. For example the modules may beembodied as part of an exchange 100 for financial instruments.

The trading network environment shown in FIG. 1 includes exemplarycomputer devices 114, 116, 118, 120 and 122 which depict differentexemplary methods or media by which a computer device may be coupledwith the exchange computer system 100 or by which a user maycommunicate, e.g., send and receive, trade or other informationtherewith. It should be appreciated that the types of computer devicesdeployed by traders and the methods and media by which they communicatewith the exchange computer system 100 is implementation dependent andmay vary and that not all of the depicted computer devices and/ormeans/media of communication may be used and that other computer devicesand/or means/media of communications, now available or later developedmay be used. Each computer device, which may comprise a computer 200described in more detail below with respect to FIG. 2 , may include acentral processor that controls the overall operation of the computerand a system bus that connects the central processor to one or moreconventional components, such as a network card or modem. Each computerdevice may also include a variety of interface units and drives forreading and writing data or files and communicating with other computerdevices and with the exchange computer system 100. Depending on the typeof computer device, a user can interact with the computer with akeyboard, pointing device, microphone, pen device or other input devicenow available or later developed.

An exemplary computer device 114 is shown directly connected to exchangecomputer system 100, such as via a T1 line, a common local area network(LAN) or other wired and/or wireless medium for connecting computerdevices, such as the network 220 shown in FIG. 2 and described belowwith respect thereto. The exemplary computer device 114 is further shownconnected to a radio 132. The user of radio 132, which may include acellular telephone, smart phone, or other wireless proprietary and/ornon-proprietary device, may be a trader or exchange employee. The radiouser may transmit orders or other information to the exemplary computerdevice 114 or a user thereof. The user of the exemplary computer device114, or the exemplary computer device 114 alone and/or autonomously, maythen transmit the trade or other information to the exchange computersystem 100.

Exemplary computer devices 116 and 118 are coupled with a local areanetwork (“LAN”) 124 which may be configured in one or more of thewell-known LAN topologies, e.g., star, daisy chain, etc., and may use avariety of different protocols, such as Ethernet, TCP/IP, etc. Theexemplary computer devices 116 and 118 may communicate with each otherand with other computer and other devices which are coupled with the LAN124. Computer and other devices may be coupled with the LAN 124 viatwisted pair wires, coaxial cable, fiber optics or other wired orwireless media. As shown in FIG. 1 , an exemplary wireless personaldigital assistant device (“PDA”) 122, such as a mobile telephone, tabletbased compute device, or other wireless device, may communicate with theLAN 124 and/or the Internet 126 via radio waves, such as via Wi-Fi,Bluetooth and/or a cellular telephone based data communicationsprotocol. PDA 122 may also communicate with exchange computer system 100via a conventional wireless hub 128.

FIG. 1 also shows the LAN 124 coupled with a wide area network (“WAN”)126 which may be comprised of one or more public or private wired orwireless networks. In one embodiment, the WAN 126 includes the Internet126. The LAN 124 may include a router to connect LAN 124 to the Internet126. Exemplary computer device 120 is shown coupled directly to theInternet 126, such as via a modem, DSL line, satellite dish or any otherdevice for connecting a computer device to the Internet 126 via aservice provider therefore as is known. LAN 124 and/or WAN 126 may bethe same as the network 220 shown in FIG. 2 and described below withrespect thereto.

As was described above, the users of the exchange computer system 100may include one or more market makers 130 which may maintain a market byproviding constant bid and offer prices for a derivative or security tothe exchange computer system 100, such as via one of the exemplarycomputer devices depicted. The exchange computer system 100 may alsoexchange information with other match or trade engines, such as tradeengine 138. One skilled in the art will appreciate that numerousadditional computers and systems may be coupled to exchange computersystem 100. Such computers and systems may include clearing, regulatoryand fee systems.

The operations of computer devices and systems shown in FIG. 1 may becontrolled by computer-executable instructions stored on anon-transitory computer-readable medium. For example, the exemplarycomputer device 116 may store computer-executable instructions forreceiving order information from a user, transmitting that orderinformation to exchange computer system 100 in electronic messages,extracting the order information from the electronic messages, executingactions relating to the messages, and/or calculating values fromcharacteristics of the extracted order to facilitate matching orders andexecuting trades. In another example, the exemplary computer device 118may include computer-executable instructions for receiving market datafrom exchange computer system 100 and displaying that information to auser. In another example, the exemplary computer device 118 may includea non-transitory computer-readable medium that stores instructions forpredicting and/or publishing a current response time or current matchengine latency as described herein.

Of course, numerous additional servers, computers, handheld devices,personal digital assistants, telephones and other devices may also beconnected to exchange computer system 100. Moreover, one skilled in theart will appreciate that the topology shown in FIG. 1 is merely anexample and that the components shown in FIG. 1 may include othercomponents not shown and be connected by numerous alternativetopologies.

As shown in FIG. 1 , the exchange computer system 100 further includes amessage management module 140 which may implement, in conjunction withthe market data module 112, the disclosed mechanisms for managingelectronic messages containing financial data sent between an exchangeand a plurality of market participants, or vice versa. However, as wasdiscussed above, the disclosed mechanisms may be implemented at anylogical and/or physical point(s) through which the relevant messagetraffic, and responses thereto, flows or is otherwise accessible,including one or more gateway devices, modems, the computers orterminals of one or more traders, etc.

Referring to FIG. 2 , an illustrative embodiment of a general computersystem 200 is shown. The computer system 200 can include a set ofinstructions that can be executed to cause the computer system 200 toperform any one or more of the methods or computer based functionsdisclosed herein. The computer system 200 may operate as a standalonedevice or may be connected, e.g., using a network, to other computersystems or peripheral devices. Any of the components discussed above,such as the processor 202, may be a computer system 200 or a componentin the computer system 200. The computer system 200 may implement amatch engine, margin processing, payment or clearing function on behalfof an exchange, such as the Chicago Mercantile Exchange, of which thedisclosed embodiments are a component thereof.

In a networked deployment, the computer system 200 may operate in thecapacity of a server or as a client user computer in a client-serveruser network environment, or as a peer computer system in a peer-to-peer(or distributed) network environment. The computer system 200 can alsobe implemented as or incorporated into various devices, such as apersonal computer (PC), a tablet PC, a set-top box (STB), a personaldigital assistant (PDA), a mobile device, a palmtop computer, a laptopcomputer, a desktop computer, a communications device, a wirelesstelephone, a land-line telephone, a control system, a camera, a scanner,a facsimile machine, a printer, a pager, a personal trusted device, aweb appliance, a network router, switch or bridge, or any other machinecapable of executing a set of instructions (sequential or otherwise)that specify actions to be taken by that machine. In a particularembodiment, the computer system 200 can be implemented using electronicdevices that provide voice, video or data communication. Further, whilea single computer system 200 is illustrated, the term “system” shallalso be taken to include any collection of systems or sub-systems thatindividually or jointly execute a set, or multiple sets, of instructionsto perform one or more computer functions.

As illustrated in FIG. 2 , the computer system 200 may include aprocessor 202, e.g., a central processing unit (CPU), a graphicsprocessing unit (GPU), or both. The processor 202 may be a component ina variety of systems. For example, the processor 202 may be part of astandard personal computer or a workstation. The processor 202 may beone or more general processors, digital signal processors, applicationspecific integrated circuits, field programmable gate arrays, servers,networks, digital circuits, analog circuits, combinations thereof, orother now known or later developed devices for analyzing and processingdata. The processor 202 may implement a software program, such as codegenerated manually (i.e., programmed).

The computer system 200 may include a memory 204 that can communicatevia a bus 208. The memory 204 may be a main memory, a static memory, ora dynamic memory. The memory 204 may include, but is not limited to,computer readable storage media such as various types of volatile andnon-volatile storage media, including but not limited to random accessmemory, read-only memory, programmable read-only memory, electricallyprogrammable read-only memory, electrically erasable read-only memory,flash memory, magnetic tape or disk, optical media and the like. In oneembodiment, the memory 204 includes a cache or random access memory forthe processor 202. In alternative embodiments, the memory 204 isseparate from the processor 202, such as a cache memory of a processor,the system memory, or other memory. The memory 204 may be an externalstorage device or database for storing data. Examples include a harddrive, compact disc (“CD”), digital video disc (“DVD”), memory card,memory stick, floppy disc, universal serial bus (“USB”) memory device,or any other device operative to store data. The memory 204 is operableto store instructions executable by the processor 202. The functions,acts or tasks illustrated in the figures or described herein may beperformed by the programmed processor 202 executing the instructions 212stored in the memory 204. The functions, acts or tasks are independentof the particular type of instructions set, storage media, processor orprocessing strategy and may be performed by software, hardware,integrated circuits, firm-ware, micro-code and the like, operating aloneor in combination. Likewise, processing strategies may includemultiprocessing, multitasking, parallel processing and the like.

As shown, the computer system 200 may further include a display unit214, such as a liquid crystal display (LCD), an organic light emittingdiode (OLED), a flat panel display, a solid state display, a cathode raytube (CRT), a projector, a printer or other now known or later developeddisplay device for outputting determined information. The display 214may act as an interface for the user to see the functioning of theprocessor 202, or specifically as an interface with the software storedin the memory 204 or in the drive unit 206.

Additionally, the computer system 200 may include an input device 216configured to allow a user to interact with any of the components ofsystem 200. The input device 216 may be a number pad, a keyboard, or acursor control device, such as a mouse, or a joystick, touch screendisplay, remote control or any other device operative to interact withthe system 200.

In a particular embodiment, as depicted in FIG. 2 , the computer system200 may also include a disk or optical drive unit 206. The disk driveunit 206 may include a computer-readable medium 210 in which one or moresets of instructions 212, e.g., software, can be embedded. Further, theinstructions 212 may embody one or more of the methods or logic asdescribed herein. In a particular embodiment, the instructions 212 mayreside completely, or at least partially, within the memory 204 and/orwithin the processor 202 during execution by the computer system 200.The memory 204 and the processor 202 also may include computer-readablemedia as discussed above.

The present disclosure contemplates a computer-readable medium thatincludes instructions 212 or receives and executes instructions 212responsive to a propagated signal, so that a device connected to anetwork 220 can communicate voice, video, audio, images or any otherdata over the network 220. Further, the instructions 212 may betransmitted or received over the network 220 via a communicationinterface 218. The communication interface 218 may be a part of theprocessor 202 or may be a separate component. The communicationinterface 218 may be created in software or may be a physical connectionin hardware. The communication interface 218 is configured to connectwith a network 220, external media, the display 214, or any othercomponents in system 200, or combinations thereof. The connection withthe network 220 may be a physical connection, such as a wired Ethernetconnection or may be established wirelessly as discussed below.Likewise, the additional connections with other components of the system200 may be physical connections or may be established wirelessly.

The network 220 may include wired networks, wireless networks, orcombinations thereof. The wireless network may be a cellular telephonenetwork, an 802.11, 802.16, 802.20, or WiMAX network. Further, thenetwork 220 may be a public network, such as the Internet, a privatenetwork, such as an intranet, or combinations thereof, and may utilize avariety of networking protocols now available or later developedincluding, but not limited to, TCP/IP based networking protocols.

Embodiments of the subject matter and the functional operationsdescribed in this specification can be implemented in digital electroniccircuitry, or in computer software, firmware, or hardware, including thestructures disclosed in this specification and their structuralequivalents, or in combinations of one or more of them. Embodiments ofthe subject matter described in this specification can be implemented asone or more computer program products, i.e., one or more modules ofcomputer program instructions encoded on a computer readable medium forexecution by, or to control the operation of, data processing apparatus.While the computer-readable medium is shown to be a single medium, theterm “computer-readable medium” includes a single medium or multiplemedia, such as a centralized or distributed database, and/or associatedcaches and servers that store one or more sets of instructions. The term“computer-readable medium” shall also include any medium that is capableof storing, encoding or carrying a set of instructions for execution bya processor or that cause a computer system to perform any one or moreof the methods or operations disclosed herein. The computer readablemedium can be a machine-readable storage device, a machine-readablestorage substrate, a memory device, or a combination of one or more ofthem. The term “data processing apparatus” encompasses all apparatus,devices, and machines for processing data, including by way of example aprogrammable processor, a computer, or multiple processors or computers.The apparatus can include, in addition to hardware, code that creates anexecution environment for the computer program in question, e.g., codethat constitutes processor firmware, a protocol stack, a databasemanagement system, an operating system, or a combination of one or moreof them.

In a particular non-limiting, exemplary embodiment, thecomputer-readable medium can include a solid-state memory such as amemory card or other package that houses one or more non-volatileread-only memories. Further, the computer-readable medium can be arandom access memory or other volatile re-writable memory.

Additionally, the computer-readable medium can include a magneto-opticalor optical medium, such as a disk or tapes or other storage device tocapture carrier wave signals such as a signal communicated over atransmission medium. A digital file attachment to an e-mail or otherself-contained information archive or set of archives may be considereda distribution medium that is a tangible storage medium. Accordingly,the disclosure is considered to include any one or more of acomputer-readable medium or a distribution medium and other equivalentsand successor media, in which data or instructions may be stored.

In an alternative embodiment, dedicated hardware implementations, suchas application specific integrated circuits, programmable logic arraysand other hardware devices, can be constructed to implement one or moreof the methods described herein. Applications that may include theapparatus and systems of various embodiments can broadly include avariety of electronic and computer systems. One or more embodimentsdescribed herein may implement functions using two or more specificinterconnected hardware modules or devices with related control and datasignals that can be communicated between and through the modules, or asportions of an application-specific integrated circuit. Accordingly, thepresent system encompasses software, firmware, and hardwareimplementations.

In accordance with various embodiments of the present disclosure, themethods described herein may be implemented by software programsexecutable by a computer system. Further, in an exemplary, non-limitedembodiment, implementations can include distributed processing,component/object distributed processing, and parallel processing.Alternatively, virtual computer system processing can be constructed toimplement one or more of the methods or functionality as describedherein.

Although the present specification describes components and functionsthat may be implemented in particular embodiments with reference toparticular standards and protocols, the invention is not limited to suchstandards and protocols. For example, standards for Internet and otherpacket switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP,HTTPS) represent examples of the state of the art. Such standards areperiodically superseded by faster or more efficient equivalents havingessentially the same functions. Accordingly, replacement standards andprotocols having the same or similar functions as those disclosed hereinare considered equivalents thereof.

A computer program (also known as a program, software, softwareapplication, script, or code) can be written in any form of programminglanguage, including compiled or interpreted languages, and it can bedeployed in any form, including as a standalone program or as a module,component, subroutine, or other unit suitable for use in a computingenvironment. A computer program does not necessarily correspond to afile in a file system. A program can be stored in a portion of a filethat holds other programs or data (e.g., one or more scripts stored in amarkup language document), in a single file dedicated to the program inquestion, or in multiple coordinated files (e.g., files that store oneor more modules, sub programs, or portions of code). A computer programcan be deployed to be executed on one computer or on multiple computersthat are located at one site or distributed across multiple sites andinterconnected by a communication network.

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application specific integrated circuit).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andanyone or more processors of any kind of digital computer. Generally, aprocessor may receive instructions and data from a read only memory or arandom access memory or both. The essential elements of a computer are aprocessor for performing instructions and one or more memory devices forstoring instructions and data. Generally, a computer may also include,or be operatively coupled to receive data from or transfer data to, orboth, one or more mass storage devices for storing data, e.g., magnetic,magneto optical disks, or optical disks. However, a computer need nothave such devices. Moreover, a computer can be embedded in anotherdevice, e.g., a mobile telephone, a personal digital assistant (PDA), amobile audio player, a Global Positioning System (GPS) receiver, to namejust a few. Computer readable media suitable for storing computerprogram instructions and data include all forms of non-volatile memory,media and memory devices, including by way of example semiconductormemory devices, e.g., EPROM, EEPROM, and flash memory devices; magneticdisks, e.g., internal hard disks or removable disks; magneto opticaldisks; and CD ROM and DVD-ROM disks. The processor and the memory can besupplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subjectmatter described in this specification can be implemented on a devicehaving a display, e.g., a CRT (cathode ray tube) or LCD (liquid crystaldisplay) monitor, for displaying information to the user and a keyboardand a pointing device, e.g., a mouse or a trackball, by which the usercan provide input to the computer. Other kinds of devices can be used toprovide for interaction with a user as well. Feedback provided to theuser can be any form of sensory feedback, e.g., visual feedback,auditory feedback, or tactile feedback. Input from the user can bereceived in any form, including acoustic, speech, or tactile input.

Embodiments of the subject matter described in this specification can beimplemented in a computing system that includes a back end component,e.g., a data server, or that includes a middleware component, e.g., anapplication server, or that includes a front end component, e.g., aclient computer having a graphical user interface or a Web browserthrough which a user can interact with an implementation of the subjectmatter described in this specification, or any combination of one ormore such back end, middleware, or front end components. The componentsof the system can be interconnected by any form or medium of digitaldata communication, e.g., a communication network. Examples ofcommunication networks include a local area network (“LAN”) and a widearea network (“WAN”), e.g., the Internet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

FIG. 3 illustrates an embodiment of market order message management asimplemented using the message management module 140 and order bookmodule 110 of the exchange computer system 100. As such, a message 10may be received from a market participant at the exchange computersystem 100 by a message receipt module 144 of the message managementmodule 140. The message receipt module 144 processes the message 10 byinterpreting the content of the message based on the message transmitprotocol, such as the transmission control protocol (“TCP”), to providethe content of the message 10 for further processing by the exchangecomputer system.

Further processing may be performed by the order extraction module 146.The order extraction module 146 may be configured to detect, from thecontent of the message 10 provided by the message receipt module 144,characteristics of an order for a transaction to be undertaken in anelectronic marketplace. For example, the order extraction module 146 mayidentify and extract order content such as a price, product, volume, andassociated market participant for an order. The order extraction module146 may also identify and extract data indicating an action to beexecuted by the exchange computer system 100 with respect to theextracted order. The order extraction module may also identify andextract other order information and other actions associated with theextracted order. All extracted order characteristics, other information,and associated actions extracted from a message for an order may becollectively considered an order as described and referenced herein.

Order or message characteristics may include, for example, the state ofthe system after a message is received, arrival time (e.g., the time amessage arrives at the MSG or Market Segment Gateway), message type(e.g., new, modify, cancel), and the number of matches generated by amessage. Order or message characteristics may also include marketparticipant side (e.g., buy or sell) or time in force (e.g., a gooduntil end of day order that is good for the full trading day, a gooduntil canceled ordered that rests on the order book until matched, or afill or kill order that is canceled if not filled immediately).

The order may be communicated from the order extraction module 146 to anorder processing module 136. The order processing module 136 may beconfigured to interpret the communicated order, and manage the ordercharacteristics, other information, and associated actions as they areprocessed through an order book module 110 and eventually transacted onan electronic market. For example, the order processing module 136 maystore the order characteristics and other content and execute theassociated actions. In an embodiment, the order processing module mayexecute an associated action of placing the order into an order book foran electronic trading system managed by the order book module 110. In anembodiment, placing an order into an order book and/or into anelectronic trading system may be considered a primary action for anorder. The order processing module 136 may be configured in variousarrangements, and may be configured as part of the order book module110, part of the message management module 140, or as an independentfunctioning module.

Certain embodiments may be applicable to other types of messagesdepending upon the implementation. Further, the messages may compriseone or more data packets, datagrams or other collection of dataformatted, arranged configured and/or packaged in a particular one ormore protocols, e.g., the FIX protocol, TCP/IP, Ethernet, etc., suitablefor transmission via a network 214 as was described, such as the messageformat and/or protocols described in U.S. Pat. No. 7,831,491 and U.S.Patent Publication No. 2005/0096999 A1, both of which are incorporatedby reference herein in their entirety. Further, the disclosed messagemanagement system may be implemented using an open message standardimplementation, such as FIX or FIX SBE (Simple Binary Encoding), or byan exchange-provided API.

In an embodiment, a plurality of electronic messages is received fromthe network. The plurality of electronic message packets may be receivedat a network interface for the electronic trading system. The pluralityof electronic messages may be sent from market participants. Theplurality of messages may include order characteristics and beassociated with actions to be executed with respect to an order that maybe extracted from the order characteristics. The action may involve anyaction as associated with transacting the order in an electronic tradingsystem. The actions may involve placing the orders within a particularmarket and/or order book of a market in the electronic trading system.

In an embodiment, the market may operate using characteristics thatinvolve collecting orders over a period of time, such as a batch auctionmarket. In such an embodiment, the period of time may be considered anorder accumulation period. The period of time may involve a beginningtime and an ending time, with orders placed in the market after thebeginning time, and the placed order matched at or after the endingtime. As such, the action associated with an order extracted from amessage may involve placing the order in the market within the period oftime. Also, electronic messages may be received prior to or after thebeginning time of the period of time.

The electronic messages may also include other data relating to theorder. In an embodiment, the other data may be data indicating aparticular time in which the action is to be executed. As such, theorder may be considered a temporally specific order. The particular timein which an action is undertaken may be established with respect to anymeasure of absolute or relative time. In an embodiment, the time inwhich an action is undertaken may be established with reference to thebeginning time of the time period or ending time of the time period in abatch auction embodiment. For example, the particular time may be aspecific amount of time, such as 10 milliseconds, prior to the endingtime of an order accumulation period in the batch auction. Further, theorder accumulation period may involve dissecting the accumulation periodinto multiple consecutive, overlapping, or otherwise divided,sub-periods of time. For example, the sub-periods may involve distincttemporal windows within the order accumulation period. As such, theparticular time may be an indicator of a particular temporal windowduring the accumulation period. For example, the particular time may bespecified as the last temporal window prior to the ending time of theaccumulation period.

In an embodiment, the electronic message may also include other actionsto be taken with respect to the order. These other actions may beactions to be executed after the initial or primary action associatedwith the order. For example, the actions may involve modifying orcanceling an already placed order. Further, in an embodiment, the otherdata may indicate order modification characteristics. For example, theother data may include a price or volume change in an order. The otheractions may involve modifying the already placed order to align with theorder modification characteristics, such as changing the price or volumeof the already placed order.

In an embodiment, other actions may be dependent actions. For example,the execution of the actions may involve a detection of an occurrence ofan event. Such triggering events may be described as other data in theelectronic message. For example, the triggering event may be a releaseof an economic statistic from an organization relating to a productbeing bought or sold in the electronic market, a receipt of pricinginformation from a correlated electronic market, a detection of a changein market sentiment derived from identification of keywords in socialmedia or public statements of official related to a product being boughtor sold in the electronic market, and/or any other event or combinationof events which may be detected by an electronic trading system.

In an embodiment, the action, or a primary action, associated with anorder may be executed. For example, an order extracted from electronicmessage order characteristics may be placed into a market, or anelectronic order book for a market, such that the order may be matchedwith other order counter thereto.

In an embodiment, an incoming transaction may be received. The incomingtransaction may be from, and therefore associated with, a marketparticipant of an electronic market managed by an electronic tradingsystem. The transaction may involve an order as extracted from areceived message, and may have an associated action. The actions mayinvolve placing an order to buy or sell a financial product in theelectronic market, or modifying or deleting such an order. In anembodiment, the financial product may be based on an associatedfinancial instrument which the electronic market is established totrade.

In an embodiment, the action associated with the transaction isdetermined. For example, it may be determined whether the incomingtransaction comprises an order to buy or sell a quantity of theassociated financial instrument or an order to modify or cancel anexisting order in the electronic market. Orders to buy or sell andorders to modify or cancel may be acted upon differently by theelectronic market. For example, data indicative of differentcharacteristics of the types of orders may be stored.

In an embodiment, data relating to the received transaction is stored.The data may be stored in any device, or using any technique, operableto store and provide recovery of data. For example, a memory 204 orcomputer readable medium 210, may be used to store data, as is describedabove with respect to FIG. 2 . Data may be stored relating receivedtransactions for a period of time, indefinitely, or for a rolling mostrecent time period such that the stored data is indicative of the marketparticipant's recent activity in the electronic market.

FIG. 4 illustrates a block diagram of a conceptual system 400 forproviding triangulation between a futures CLOB 405, a premium optionsCLOB 408, and a volatility CLOB 430 for incoming orders to trade afinancial product, received via a network, such as the network 126 ofFIG. 1 , from a plurality of market participants. FIG. 4 includes threesections, the volatility quoting model execution section 444 whereorders may be received and normalized; a real order section forvolatility quoting 434; and an implication section 404 where orders areimplied into the FUT CLOB 405 and PQO CLOB 408.

The volatility quoting model Execution 444 section may receive andnormalize volatility quoted orders. Customer models may be received andstored in memory. When a volatility quoted order is received from acustomer, the transaction message may indicate a specific model used bythe customer. A normalization component 440 may then use a stored custommodel 450 or table or database to normalize the Volatility to astandardized value that may be used to match orders from other customersthat may be residing in the VQO CLOB 430. The Vol quoting modelExecution section 444 may contain multiple models 450 for one or morecustomers.

The real order section for volatility quoting 434 is configured tooperate as a normal matching engine. This section receives normalizedvolatility Quotes from the Vol quoting model Execution section 444 andattempts to match them with any resting orders that exist on the VQOCLOB 430. If the match engine identifies one or more suitable previouslyreceived but unsatisfied counter orders, they, and the normalizedvolatility quoted order, are matched to execute a trade there between toat least partially satisfy the quantities of one or both the incomingorder or the identified orders. If there remains any residualunsatisfied quantity of the identified one or more orders, those ordersare left on the order book with their remaining quantity to await asubsequent suitable counter order, i.e. to rest. If the match enginedoes not identify a suitable previously received but unsatisfied counterorder, or the one or more identified suitable previously received butunsatisfied counter orders are for a lesser quantity than the incomingorder, the incoming order is placed on the order book, referred to as“resting”, with original or remaining unsatisfied quantity, to await asubsequently received suitable order counter thereto. The match enginethen generates match event data reflecting the result of this matchingprocess.

The Implication section 404 may be where orders are implied into the FUTCLOB 405 and PQO CLOB 406. The futures market 410 may be locked prior toimplication and may remained locked while orders are being implied.Implied orders, unlike real orders, are generated by electronic tradingsystems. In other words, implied orders are computer generated ordersderived from real orders. The system creates the “derived” or “implied”order and provides the implied order as a market that may be tradedagainst. If a trader trades against this implied order, then the realorders that combined to create the implied order and the resultingmarket are executed as matched trades. Implied orders generally increaseoverall market liquidity. The creation of implied orders increases thenumber of tradable items, which has the potential of attractingadditional traders. Exchanges benefit from increased transaction volume.Transaction volume may also increase as the number of matched tradeitems increases.

FIG. 5 depicts a block diagram of a system 500, that may also bereferred to as an architecture, for providing triangulation between afutures CLOB, a premium options CLOB, and a volatility CLOB for incomingorders to trade a financial product, received via a network, such as thenetwork 126 of FIG. 1 , from a plurality of market participants.Wherein, as described, the system 500 comprising a match engine/matchprocessor 106 that implements a market for an associated financialinstrument by being operative to attempt to match an incoming order fora transaction for the associated financial instrument with at least oneother previously received but unsatisfied order for a transactioncounter thereto for the associated financial instrument, to at leastpartially satisfy one or both of the incoming order or the at least oneother previously received order. A match engine/match processor may be ahardware matching processor that is part of a transaction processingsystem. A data transaction processing system in which data items aretransacted by a hardware matching processor that matches electronic datatransaction request messages for the same one of the data items based onmultiple transaction parameters from different client computers over adata communication network. The match engine 106 may be connected to theconnected into a switch 501 with either a single or dual physicalconnection. Single if both inbound (orders) and outbound (market data,acks, etc.) may be sent on the same wire. Dual if inbound (orders) andoutbound (market data, acks, etc.) may be sent separately. The matchingengine 106 may be responsible for performing the triangulation betweenfuture, premium and VQO CLOB's. The PQO injector, the Futures Injector,and the Vol Quoting Injector may reside on the same physicalinfrastructure or may be separate implementations.

The system 500 includes a Switch/Bus 208 that is connected to each ofthe other nodes. Communications between the components may be encodedeither through source (.hpp, .h, .etc.) or via library.

The system 500 includes a futures injector 505, that may be implementedas a separate component or as one or more logic components, such as onan FPGA that may include a memory or reconfigurable component to storelogic and processing component to execute the stored logic, or ascomputer program logic, stored in a memory 204, or other non-transitorycomputer readable medium, and executable by a processor 202, such as theprocessor 202 and memory 204 described below with respect to FIG. 4 , tocause the processor 202 to, or otherwise be operative to, inject futuresinto the match engine 106. The Futures Injector may be a component thatmay be capable of injecting futures into the matching engine and/ororder book module 110. The future injector 505 may use a specificmessaging format and protocol via API (struct, library, etc.).

The system 500 includes a premium quoted options injector 510, that maybe implemented as a separate component or as one or more logiccomponents, such as on an FPGA that may include a memory orreconfigurable component to store logic and processing component toexecute the stored logic, e.g. computer program logic, stored in amemory 204, or other non-transitory computer readable medium, andexecutable by a processor 202, such as the processor 202 and memory 404described below with respect to FIG. 4 , to cause the processor 202 to,or otherwise be operative to, inject options into the match engine 106.The premium options injector 510 may be a component that may be capableof injecting PQO into the matching engine and/or order book module 110.The premium options injector 510 may use a specific messaging format andprotocol via API (struct, library, etc.).

The system 500 further includes an Vol Quoting Injector 515, that may beimplemented as a separate component or as one or more logic components,such as on an FPGA that may include a memory or reconfigurable componentto store logic and processing component to execute the stored logic,e.g. computer program logic, stored in a memory 204, or othernon-transitory computer readable medium, and executable by a processor202, such as the processor 202 and memory 204 described below withrespect to FIG. 4 , to cause the processor 202 to, or otherwise beoperative to inject volatility quotes into the match engine 106 and/ororder book module 110.

The system 500 further includes a Collector 520, coupled with the memory204, the match engine 106, and that may be implemented as a separatecomponent or as one or more logic components, such as on an FPGA thatmay include a memory or reconfigurable component to store logic andprocessing component to execute the stored logic e.g. computer programlogic, stored in a memory 204, or other non-transitory computer readablemedium, and executable by a processor 202, such as the processor 202 andmemory 204 described below with respect to FIG. 4 , to cause theprocessor 202 to, or otherwise be operative to, upon the occurrence ofthe event, forward at least a subset of the stored received incomingorders to the match engine 106. The collector 520 may be a componentthat may receive the output from the engine and correlate the messagesto in the inbound orders/quotes in order to measure performance. Theremay be additional infrastructure inline performing the capture in orderto provide high-resolution timing for each message as seen by theexchange and consumer.

FIG. 6 depicts a flow chart showing operation of the system 500 of FIG.5 . In particular FIG. 5 shows a computer implemented method oftriangulating orders in an electronic trading system 100, the electronictrading system 100 comprising a match engine 106 that implements amarket for an associated financial instrument by being operative toattempt to match an incoming order for a transaction for the associatedfinancial instrument with at least one other previously received butunsatisfied order for a transaction counter thereto for the associatedfinancial instrument, to at least partially satisfy one or both of theincoming order or the at least one other previously received order.

At block 601, the system receives an incoming transaction. Thetransaction may be an order quoted in volatility. The incomingtransaction may be from, and therefore associated with, a marketparticipant of an electronic market managed by an electronic tradingsystem. The transaction may involve an order as extracted from areceived message, and may have an associated action. The actions mayinvolve placing an order to buy or sell a financial product in theelectronic market, or modifying or deleting such an order. In anembodiment, the financial product may be based on an associatedfinancial instrument that the electronic market is established to trade.The transaction may be alternatively an order quoted in premiums, and/ora futures order.

In an embodiment, the action associated with the transaction isdetermined. For example, it may be determined whether the incomingtransaction comprises an order to buy or sell a quantity of theassociated financial instrument or an order to modify or cancel anexisting order in the electronic market. Orders to buy or sell andorders to modify or cancel may be acted upon differently by theelectronic market. For example, data indicative of differentcharacteristics of the types of orders may be stored.

In an embodiment, data relating to the received transaction is stored.The data may be stored in any device, or using any technique, operableto store and provide recovery of data. For example, a memory 204 orcomputer readable medium 210, may be used to store data, as is describedabove with respect to FIG. 2 . Data may be stored relating receivedtransactions for a period of time, indefinitely, or for a rolling mostrecent time period such that the stored data is indicative of the marketparticipant's recent activity in the electronic market.

In an embodiment, a received order may already be standardized to anoptions pricing model known by the exchange. In certain embodiments, thecustomer may have previously transmitted an options pricing model to thesystem that may use a customized equation for volatility. Volatility isa statistical measurement of the degree of fluctuation of a market orsecurity. Implied volatility is the volatility as implied by the marketprice of the option. The implied volatility is calculated using anoption pricing model, such as the Black model, in which a mathematicalrelationship between the volatility of the underlying security and theprice of its options has been established. Implied volatility is themarket's opinion of the volatility of the option's underlying securityand is determined using the following information: the price of theunderlying security, the market price of the option, the strike price ofthe option, the expiration date of the option, the interest rate, ifapplicable, and the dividend yield, if applicable.

Implied volatility and premiums are related through use of optionspricing models. For example, using a pricing model, the impliedvolatility of an option may be backed out of the price of the option.Models such as Black, Whaley, or Merton (or customized models) allow atrader or exchange to use implied volatility to evaluate an optionsprice or vice versa. Each customer, however, may use a different modelto calculate volatility.

In certain embodiments, if the customer is using a customized model thatis stored in memory on the exchange system, the exchange system maynormalize volatility to that of a standard model such as Black, Whaley,Merton, or Bjerksund. The exchange system may store multiple customizedmodel for each customer such as variations on the above listed models,binomial models, trinomial models, among others. The transaction mayinclude the model or a model identification that the order is quoted in.

At block 603, the match engine determines if there is a match in the VQOCLOB for the order. As mentioned above, the match engine may use one ormore matching algorithms or allocation algorithms to determine matches.If the match engine identifies one or more suitable previously receivedbut unsatisfied counter orders, they, and the incoming order, arematched to execute a trade there between to at least partially satisfythe quantities of one or both the incoming order or the identifiedorders. If there remains any residual unsatisfied quantity of theidentified one or more orders, those orders are left on the order bookwith their remaining quantity to await a subsequent suitable counterorder.

If there is a match, the process moves to block 605 where an order isimplied into the FUT CLOB. This second order is implied for anopposite-side-of-the-market futures trade. Together, the option and thefuture comprise a delta-neutral option-future combination. Certainoptions may include infinite risk. For example, for a naked call, thetheoretical risk is infinite. The customer is responsible for thedifference between the strike price and the amount the instrument movesabove this price. Because there isn't a limit to how high a price cantrade, the potential loss is infinite. In existing systems, this ordermay be made separately from the volatility quoted order. A customer mayhave to anticipate the FUT CLOB in order to determine how to mitigaterisk. With triangulation, the FUT CLOB is known to the match engine, andas such offers transparent mitigation options at the time the volatilityquoted order is matched. A benefit to this system is that a customer mayquote larger orders in volatility than are currently quoted knowing thatthey may always be covered though triangulation of the FUT CLOB. Underthe existing systems, a customer may quote a bid size of 1000. Afterthat is matched, a customer may then need to quote the delta necessarybid size over on the FUT market. The size required to mitigate at theprice desired may not be available. With triangulation, the customer mayfeel safe quoting any size bid in the volatility market, knowing thatthe match may only occur when there are available orders on the FUTmarket to mitigate the risk. Block 603 and Block 605 may occursimultaneously. With triangulation, the matching engine may beconfigured to identify the potential implied FUT order while identifyinga match in the VQO CLOB. While an order is being implied into the FUTCLOB, the futures market may be locked.

At block 607, the orders are filled. Match event data, reflecting theresult of this matching process, may be generated. The collector or amessage generator may transmit or otherwise manage communications of oneor more financial data messages to a plurality of market participantsvia a network, each of the plurality of financial data messagescomprising, for example, data indicative of the filled order, a changein state of an electronic marketplace for one or more financialproducts, e.g. market data, such as based on received orders and/orcancellation thereof, matched trades, price changes, etc. The pluralityof financial data messages may include message types which carry datarepresentative of, or otherwise represent the marketplace, or changes tothe state thereof, in different ways such as market by order messages,market by price messages, top of book messages, analytics messages, orother representations or combinations thereof. A recipient may receiveall, or otherwise choose among, the different available messagetypes/market representations. Financial data messages, or a seriesthereof, of a particular type may be referred to as a stream or marketdata stream, e.g. a market by order stream, a market by price stream, atop of book stream, etc. These market data streams may be independentlygenerated, subscribed to and modified according to the disclosedembodiments. Alternatively, one or more of these data streams may begenerated in a combined fashion. As used herein, the plurality offinancial messages may refer all financial data messages generated asdescribed wherein one or more subsets of the plurality of financial datamessages may be of a particular type.

At block 609 if the match engine does not identify a suitable previouslyreceived but unsatisfied counter order, or the one or more identifiedsuitable previously received but unsatisfied counter orders are for alesser quantity than the incoming order, the incoming order is placed onthe VQO CLOB, referred to as “resting”, with original or remainingunsatisfied to await a subsequently received suitable order counterthereto. An implied order may also be left on the FUT CLOB.

At block 611, if no match is found in the VQO CLOB, the FUT market maybe locked. Locked may refer to the market or priced being frozen at acertain point in time. The current FUT price may be used in subsequentcalculations which requires that the price be locked until any modelsthat use the FUT price have been executed and implication into the PQOCLOB is complete. The FUT market may be locked by only calculating orreporting a price at a certain interval. For example, if the FUT marketis only updated every seconds, then between seconds, the market wouldappear to be frozen or locked. The time needed to calculate and imply anorder into the PQO CLOB may regulate how the FUT market is updated.

In certain embodiments, the FUT market is locked after receiving amessage from the match engine. The FUT market may be unlocked after acertain period of time or after receiving a message or command tounlock.

At block 613, an implied order is generated using the model and thecurrent futures price. The order is implied into the PQO CLOB. Impliedorders, unlike real orders, are generated by electronic trading systems.In other words, implied orders are computer generated orders derivedfrom real orders. The system creates the “derived” or “implied” orderand provides the implied order as a market that may be traded against.If a trader trades against this implied order, then the real orders thatcombined to create the implied order and the resulting market areexecuted as matched trades. Implied orders generally increase overallmarket liquidity. The creation of implied orders increases the number oftradable items. This has the potential of attracting additional traders.Exchanges benefit from increased transaction volume. Transaction volumemay also increase as the number of matched trade items increases.

At block 615, the match engine determines if there is a match in the PQOCLOB for the order. As mentioned above, the match engine may use one ormore matching algorithms or allocation algorithms to determine matches.In one embodiment the matching algorithms may comprise a pro-rataalgorithm, a first in first out (“FIFO”) algorithm, a Price ExplicitTime algorithm, an Order Level Pro Rata algorithm, an Order LevelPriority Pro Rata algorithm, a Preference Price Explicit Time algorithm,a Preference Order Level Pro Rata algorithm, a Preference Order LevelPriority Pro Rata algorithm, a Threshold Pro-Rata algorithm, a PriorityThreshold Pro-Rata algorithm, a Preference Threshold Pro-Rata algorithm,a Priority Preference Threshold Pro-Rata algorithm, a Split Price-TimePro-Rata algorithm, or combinations thereof.

If the match engine identifies one or more suitable previously receivedbut unsatisfied counter orders, they, and the incoming order, arematched to execute a trade there between to at least partially satisfythe quantities of one or both the incoming order or the identifiedorders. If there remains any residual unsatisfied quantity of theidentified one or more orders, those orders are left on the PQO CLOBwith their remaining quantity to await a subsequent suitable counterorder, i.e. to resting quantity, to await a subsequently receivedsuitable order counter thereto.

If there is a match, the process moves to block 617 where an order maybe implied into the FUT CLOB. This second order is implied for anopposite-side-of-the-market futures trade. Together, the option and thefuture comprise a delta-neutral option-future combination. Certainoptions may include infinite risk. For example, for a naked call, thetheoretical risk is infinite. The customer is responsible for thedifference between the strike price and the amount the instrument movesabove this price. Because there isn't a limit to how high a price cantrade, the potential loss is infinite. In existing systems, this ordermay be made separately from the volatility quoted order. A customer mayhave to anticipate the FUT CLOB in order to determine how to mitigaterisk. With triangulation, the FUT CLOB is known to the match engine, andas such offers transparent mitigation options at the time the PQO ismatched. A benefit to this system is that a customer may quote largerorders than are currently quoted knowing that they may always be coveredthough triangulation of the FUT CLOB. Under the existing systems, acustomer may quote a bid size of 1000. After that is matched, a customermay then need to quote the delta necessary bid size over on the FUTmarket. The size required to mitigate at the price desired may not beavailable. With triangulation, the customer may feel safe quoting anysize bid in the market, knowing that the match may only occur when thereare available orders on the FUT market to mitigate the risk. Block 525and Block 540 may occur simultaneously. With triangulation, the matchingengine may be configured to identify the potential implied FUT orderwhile identifying a match in the PQO CLOB.

At block 619, any matched orders are filled/completed. Because this isan implied order, filling (or completing) this order may affect anoriginal order that may be resting on the VQO CLOB. Match event data,reflecting the result of this matching process, may be generated. Thecollector or a message generator may transmit or otherwise managecommunications of one or more financial data messages to a plurality ofmarket participants via a network, each of the plurality of financialdata messages comprising, for example, data indicative of the filledorder, a change in state of an electronic marketplace for one or morefinancial products, e.g. market data, such as based on received ordersand/or cancellation thereof, matched trades, price changes, etc. Theplurality of financial data messages may include message types whichcarry data representative of, or otherwise represent the marketplace, orchanges to the state thereof, in different ways such as market by ordermessages, market by price messages, top of book messages, analyticsmessages, or other representations or combinations thereof. A recipientmay receive all, or otherwise choose among, the different availablemessage types/market representations. Financial data messages, or aseries thereof, of a particular type may be referred to as a stream ormarket data stream, e.g. a market by order stream, a market by pricestream, a top of book stream, etc. These market data streams may beindependently generated, subscribed to and modified according to thedisclosed embodiments. Alternatively, one or more of these data streamsmay be generated in a combined fashion. As used herein, the plurality offinancial messages may refer all financial data messages generated asdescribed wherein one or more subsets of the plurality of financial datamessages may be of a particular type.

At block 621 if the match engine does not identify a suitable previouslyreceived but unsatisfied counter order, or the one or more identifiedsuitable previously received but unsatisfied counter orders are for alesser quantity than the incoming order, the incoming order is placed onthe PQO CLOB, referred to as “resting”, with original or remainingunsatisfied to await a subsequently received suitable order counterthereto

At block 623, the FUT market is unlocked. Depending on the mechanisminvolved, the FUT market may unlock automatically after a certain amountof time.

At block 625, the futures market is observed for any changes. If themarket changes, the process moves to block 627. Until the marketchanges, the futures market is continuously watched.

At block 627, once the future price has changed, the implied orders isre-calculated using the new FUT price and a standard options pricingmodel (or a previously received and stored customized model). Inexisting systems, a trader may have had to maintain these orderthemselves which involves large amounts of messaging and communicationsbetween the trader and the exchange. By calculating and re-calculatingthese order on the exchange side, this decreases the amount of trafficgoing back and forth between the exchange and the trader.

This loop may repeat until a match is made on any of the books or theorder is withdrawn. If the FUT price changes enough to affectvolatility, the system may receive new quotes from a customer.

The scenario described by FIG. 6 illustrates an example where a customerhas submitted an order quoting volatility and the order is then impliedinto the PDO CLOB. An example of this scenario is shown below in CALLScenario #1. Two additional scenarios are described below which involvetriangulation between the three books. In each of these scenarios thereis the assumption that time to expiration=24 days, the interest rate is1%, and the orders involve European style options.

CALL Scenario #1: Customer quoting the Vol market and implying into thePQO.

-   -   Given—    -   |Futures Book|PQO 135 strike Call|    -   ---------------------------------------------------------------    -   |10@1.3500/None|Empty|    -   Vol Book: Empty    -   Configuration: Imply into PQO CLOB    -   When—    -   #1: Bid Vol 30 @ 10.00    -   #2: Offer Vol 50 @ 10.05    -   Then—    -   #1: VQO CLOB Bid 30 @ 10.00    -   #2: VQO CLOB Offer 50 @ 10.05    -   #3: PQO CLOB Implies Bid 20 @ 0.0138    -   Note: PQOImpliedBidQty=_min(VQOBidQty,        FutureBidQty/Delta)=_min(30, 10/0.505093)=_min (30, 19.798)=20

For CALL Scenario #1, the customer quotes the Vol market with a bid of30@ 10.00 and an offer of 50@ 10.05. Both these orders are added to theVQO CLOB in #1 and #2. Next, an offer is implied into the PQO CLOB. Thisis limited to 20@0.0138 due to the requirement that the Vol quote bemitigated with an opposite-side-of-the-market futures trade. ThePQOImpliedBidQty is therefore limited to 20 as the lesser of 30 or theavailable futures market to mitigate.

In certain embodiments orders may be received quoting premiums andimplied into the volatility market or futures market. A customer mayquote the futures market and imply into the Vol or PQO market. Acustomer may quote the Vol market and be implied into both the PQOmarket and the futures market. Triangulation allows for each of thethree books to imply into one another, increasing liquidity in eachmarket.

CALL Scenario #2 below describes a situation where a customer quotes theVol Market and is implied into the Futures CLOB.

-   -   Given:    -   |Futures Book|PQO ¿ 135 strike Call 1    -   ---------------------------------------------------------------    -   |[10 @] 1.3500/None|None/40 @ 0.0142|    -   Vol Book: Empty    -   Configuration: Imply into Futures CLOB    -   When—    -   #1: Bid Vol 30 @ 10.00    -   #2: Offer Vol 50 @ 10.05    -   Then—    -   #1: VQO CLOB Bid 30 @ 10.00    -   #2: VQO CLOB Offer 50 @ 10.05    -   #3: Futures CLOB Implies Offer 15 @ 1.3508    -   Note: Future Qty=_min(Delta*PQOAskQty,        Delta*QOBidQty)=_min(0.514306*40,0.514306*30)=_min(20.57724,        15.42918)

For CALL Scenario #2, the customer quotes the Vol market with a bid of30@ 10.00 and an offer of 50@ 10.05. Both these orders are added to theVQO CLOB in #1 and #2. Next, at #3 an offer is implied into the FuturesCLOB. For mitigation reasons, the order implied into the Futures CLOB islimited to 15@ 1.3508.

CALL Scenario #3: Customer quoting the Vol market and implying into theFutures and Premium. Given:

-   -   |Futures Book|PQO ¿ 135 strike Call|    -   ---------------------------------------------------------------    -   |10 @ 1.3500/30 @ 1.35021 20 @ 0.0136−40 @ 0.0142|    -   Vol Book: Empty    -   Configuration: Imply into Futures and Premium    -   When—    -   #1: Bid Vol 30 @ 10.00    -   #2: Offer Vol 50 @ 10.05    -   Then—    -   #1: VQO CLOB Bid 30 @ 10    -   #2: VQO CLOB Offer 50 @ 10.05    -   #3: Futures CLOB Implies Bid 10 @ 1.3494    -   Note: FutureQty=PQODelta*PQOBidQty=0.498237*20=9.964)    -   #4: Futures CLOB Implies Offer 20 @ 1.3508 or 21 @ 1.3508 (qty        round up)    -   Note: FutureQty=PQODelta*PQOAskQty=0.514306*40=20.57724)    -   #5: PQO CLOB Implies Bid 20 @ 0.0138    -   Note: PQOImpliedBidQty=_min(Delta*VQOBidQty,        FutureBidQty/Delta)=_min(30, 10/0.505093)=_min (15.15279,        19.798)=15    -   #6: PQO CLOB Implies Offer 50 @ 0.0140    -   Note: PQOImpliedAskQty=_min(Delta*VQOAskQty,        FutureAskQty/Delta)=_min(50, 30/0.507411)=_min (50, 59.12366)=50

For CALL Scenario #3, the customer quotes the Vol market with a bid of30@ 10.00 and an offer of 50@ 10.05. Both these orders are added to theVQO CLOB in #1 and #2. A 20 @ 0.0138 bid and 50 @ 0.0140 offer areimplied into the PQO CLOB.

The illustrations of the embodiments described herein are intended toprovide a general understanding of the structure of the variousembodiments. The illustrations are not intended to serve as a completedescription of all of the elements and features of apparatus and systemsthat utilize the structures or methods described herein. Many otherembodiments may be apparent to those of skill in the art upon reviewingthe disclosure. Other embodiments may be utilized and derived from thedisclosure, such that structural and logical substitutions and changesmay be made without departing from the scope of the disclosure.Additionally, the illustrations are merely representational and may notbe drawn to scale. Certain proportions within the illustrations may beexaggerated, while other proportions may be minimized. Accordingly, thedisclosure and the figures are to be regarded as illustrative ratherthan restrictive.

While this specification contains many specifics, these should not beconstrued as limitations on the scope of the invention or of what may beclaimed, but rather as descriptions of features specific to particularembodiments of the invention. Certain features that are described inthis specification in the context of separate embodiments can also beimplemented in combination in a single embodiment.

Conversely, various features that are described in the context of asingle embodiment can also be implemented in multiple embodimentsseparately or in any suitable sub-combination. Moreover, althoughfeatures may be described above as acting in certain combinations andeven initially claimed as such, one or more features from a claimedcombination can in some cases be excised from the combination, and theclaimed combination may be directed to a sub-combination or variation ofa sub-combination.

Similarly, while operations are depicted in the drawings and describedherein in a particular order, this should not be understood as requiringthat such operations be performed in the particular order shown or insequential order, or that all illustrated operations be performed, toachieve desirable results. In certain circumstances, multitasking andparallel processing may be advantageous. Moreover, the separation ofvarious system components in the embodiments described above should notbe understood as requiring such separation in all embodiments, and itshould be understood that the described program components and systemscan generally be integrated together in a single software product orpackaged into multiple software products.

One or more embodiments of the disclosure may be referred to herein,individually and/or collectively, by the term “invention” merely forconvenience and without intending to voluntarily limit the scope of thisapplication to any particular invention or inventive concept. Moreover,although specific embodiments have been illustrated and describedherein, it should be appreciated that any subsequent arrangementdesigned to achieve the same or similar purpose may be substituted forthe specific embodiments shown. This disclosure is intended to cover anyand all subsequent adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, will be apparent to those of skill in theart upon reviewing the description.

The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b) and is submitted with the understanding that it will not be usedto interpret or limit the scope or meaning of the claims. In addition,in the foregoing Detailed Description, various features may be groupedtogether or described in a single embodiment for the purpose ofstreamlining the disclosure. This disclosure is not to be interpreted asreflecting an intention that the claimed embodiments require morefeatures than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive subject matter may be directed toless than all of the features of any of the disclosed embodiments. Thus,the following claims are incorporated into the Detailed Description,with each claim standing on its own as defining separately claimedsubject matter.

It is therefore intended that the foregoing detailed description beregarded as illustrative rather than limiting, and that it be understoodthat it is the following claims, including all equivalents, that areintended to define the spirit and scope of this invention.

What is claimed is:
 1. A computer implemented method comprising:receiving, by an order processor via an electronic communicationsnetwork, a first electronic data transaction request message comprisingdata indicative of a first order for a first product specifying a firstvalue characterized by a first convention; determining, based on thefirst value by a hardware matching processor coupled with the orderprocessor and with a first order book data structure stored in thememory which stores data indicative of previously received butunsatisfied orders each having a value characterized by the firstconvention, that the first order is not fully satisfied by any of thepreviously received but unsatisfied orders, and based thereon:preventing, by the order processor, modifications to the first orderbook data structure; determining, subsequent to the preventing, by theorder processor, a current value of the condition and generating, basedthereon using a model unique to a sender of the first electronic datatransaction request message and which enables conversion, as a functionof a condition to be determined subsequent to the retrieval of themodel, the first value to a plurality of second values characterized bya second convention related to the first convention, a plurality offirst implied orders for a second product, based on the unsatisfiedremainder of the first order, each specifying one of the plurality ofsecond values; matching, by the hardware matching processor, one or moreof the plurality of first implied orders with one or more previouslyreceived but unsatisfied orders counter thereto stored in a second orderbook data structure based on the second value, both the satisfiedportion of the first order and any of the previously received butunsatisfied orders for the second product which matched any of theplurality of first implied orders being thereby completed, the secondorder book data structure being updated to store data indicative of anyof the plurality of first implied orders which thereafter remainunsatisfied; and enabling, subsequent to the matching, by the orderprocessor, the first order book data structure to be modified.
 2. Thecomputer implemented method of claim 1, wherein the first conventioncomprises a volatility, the second convention comprises a premium, themethod further comprising: generating, automatically by the orderprocessor based on the completion of the first order, a second impliedorder for a third product having a third value in a third order bookdata structure, the third product related to the first product, thesecond implied order, when completed, being characterized by a riskvalue wherein a net of the risk value and a risk value of the firstorder is less than the risk value of the first order; and, wherein thesecond implied order is a futures order.
 3. The computer implementedmethod of claim 2, wherein the first order and the second implied ordercomprise a delta-neutral option-future combination.
 4. The computerimplemented method of claim 3, wherein the amount of the first ordercompleted is limited to a size of the second implied order completed inorder to comprise the delta-neutral option-future combination.
 5. Thecomputer implemented method of claim 4, wherein the unsatisfied portionof the first order resulting from the unsatisfied portion of theplurality of first implied orders is left as a resting order on thefirst order book data structure, and the second implied order is basedon the unsatisfied portion of the first order.
 6. The computerimplemented method of claim 1, further comprising: determining,automatically periodically by the order processor, whether the conditionhas changed and, based thereon: preventing, by the order processor,modifications to the first order book data structure; determining,subsequent to the preventing by the order processor, the current valueof the condition and updating, based thereon using the model, the secondvalues any of the plurality of first implied orders stored in the secondorder book data structure; and enabling, subsequent to the determiningby the order processor, the first order book data structure to bemodified.
 7. The computer implemented method of claim 1, wherein thewherein the model comprises an options pricing model including Whaley,Black, or Bjerksund.
 8. A system comprising: a processor and a memorycoupled therewith, the memory storing computer executable instructionsthat when executed by the processor cause the processor to: receive, viaan electronic communications network, a first electronic datatransaction request message comprising data indicative of a first orderfor a first product specifying a first value characterized by a firstconvention; receive, from a hardware matching processor coupled with theprocessor and with a first order book data structure stored in thememory which stores data indicative of previously received butunsatisfied orders each having a value characterized by the firstconvention, a determination, based on the first value, that the firstorder is not fully satisfied by any of the previously received butunsatisfied orders, and based thereon: prevent modifications to thefirst order book data structure; determine, subsequent to thepreventing, a current value of the condition and generating, basedthereon using a model unique to a sender of the first electronic datatransaction request message and which enables conversion, as a functionof a condition to be determined subsequent to the retrieval of themodel, the first value to a plurality of second values characterized bya second convention related to the first convention, a plurality offirst implied orders for a second product, based on the unsatisfiedremainder of the first order, each specifying one of the plurality ofsecond values; enable the hardware matching processor to match one ormore of the plurality of first implied orders with one or morepreviously received but unsatisfied orders counter thereto stored in asecond order book data structure based on the second value, both thesatisfied portion of the first order and any of the previously receivedbut unsatisfied orders for the second product which matched any of theplurality of first implied orders being thereby completed, the secondorder book data structure being updated to store data indicative of anyof the plurality of first implied orders which thereafter remainunsatisfied; and enable, subsequent to the matching, by the orderprocessor, the first order book data structure to be modified.
 9. Thesystem of claim 8, wherein the first convention comprises a volatility,the second convention comprises a premium, the computer executableinstructions being further operative to cause the processor to:generate, automatically based on the completion of the first order, asecond implied order for a third product having a third value in a thirdorder book data structure, the third product related to the firstproduct, the second implied order, when completed, being characterizedby a second risk value wherein a net of the risk value and a risk valueof the first order is less than the risk value of the first order; and,wherein the second implied order is a futures order.
 10. The system ofclaim 9, wherein the first order and the second implied order comprise adelta-neutral option-future combination.
 11. The system of claim 10,wherein the amount of the first order completed is limited to a size ofthe second implied order completed in order to comprise thedelta-neutral option-future combination.
 12. The system of claim 11,wherein the unsatisfied portion of the first order resulting from theunsatisfied portion of the plurality of first implied orders is left asa resting order on the first order book data structure, and the secondimplied order is based on the unsatisfied portion of the first order.13. The system of claim 8, wherein the computer executable instructionsare further operative to cause the processor to: determine,automatically periodically, whether the condition has changed and, basedthereon: prevent modifications to the first order book data structure;determine, subsequent to the preventing, the current value of thecondition and update, based thereon use the model, the second values anyof the plurality of first implied orders stored in the second order bookdata structure; and enable, subsequent to the determination, the firstorder book data structure to be modified.
 14. The system of claim 8,wherein the wherein the model comprises an options pricing modelincluding Whaley, Black, or Bjerksund.
 15. A system comprising: meansfor receiving, via an electronic communications network, a firstelectronic data transaction request message comprising data indicativeof a first order for a first product specifying a first valuecharacterized by a first convention; means for determining, based on thefirst value a first order book data structure stored in a memory whichstores data indicative of previously received but unsatisfied orderseach having a value characterized by the first convention, that thefirst order is not fully satisfied by any of the previously received butunsatisfied orders, and based thereon: means for preventingmodifications to the first order book data structure; means fordetermining, subsequent to the preventing a current value of thecondition and generating, based thereon using a model unique to a senderof the first electronic data transaction request message and whichenables conversion, as a function of a condition to be determinedsubsequent to the retrieval of the model, the first value to a pluralityof second values characterized by a second convention related to thefirst convention, a plurality of first implied orders for a secondproduct, based on the unsatisfied remainder of the first order, eachspecifying one of the plurality of second values; means for matching oneor more of the plurality of first implied orders with one or morepreviously received but unsatisfied orders counter thereto stored in asecond order book data structure based on the second value, both thesatisfied portion of the first order and any of the previously receivedbut unsatisfied orders for the second product which matched any of theplurality of first implied orders being thereby completed, the secondorder book data structure being updated to store data indicative of anyof the plurality of first implied orders which thereafter remainunsatisfied; and means for enabling, subsequent to the matching, thefirst order book data structure to be modified.
 16. The system of claim15, wherein the first convention comprises a volatility, the secondconvention comprises a premium, the system further comprising: means forgenerating, automatically based on the completion of the first order, asecond implied order for a third product having a third value in a thirdorder book data structure, the third product related to the firstproduct, the second implied order, when completed, being characterizedby a risk value wherein a net of the risk value and a risk value of thefirst order is less than the risk value of the first order; and, whereinthe second implied order is a futures order.
 17. The system of claim 16,wherein the first order and the second implied order comprise adelta-neutral option-future combination.
 18. The system of claim 17,wherein the amount of the first order completed is limited to a size ofthe second implied order completed in order to comprise thedelta-neutral option-future combination.
 19. The system of claim 18,wherein the unsatisfied portion of the first order resulting from theunsatisfied portion of the plurality of first implied orders is left asa resting order on the first order book data structure, and the secondimplied order is based on the unsatisfied portion of the first order.20. The system of claim 15, further comprising: means for determining,automatically periodically, whether the condition has changed and, basedthereon: means for preventing modifications to the first order book datastructure; means for determining, subsequent to the preventing, thecurrent value of the condition and updating, based thereon using themodel, the second values any of the plurality of first implied ordersstored in the second order book data structure; and means for enabling,subsequent to the determining, the first order book data structure to bemodified.